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EXECUTIVE SUMMARY 


The purpose of CASTOR (Cathode/ Anode Satellite Thruster for Orbital Repositioning) satellite 
is to demonstrate in Low Earth Orbit (LEO) a nanosatellite that uses a Divergent Cusped Field 
Thruster (DCFT) to perform orbital maneuvers representative of an orbital transfer vehicle. 
Powered by semi-deployable solar arrays generating 165W of power, CASTOR will achieve 
nearly 1 km/s of velocity increment over one year. As a technology demonstration mission, 
success of CASTOR in LEO will pave the way for a low cost, high delta-V orbital transfer 
capability for small military and civilian payloads in support of Air Force and NASA missions. 
The educational objective is to engage graduate and undergraduate students in critical roles in the 
design, development, test, carrier integration and on-orbit operations of CASTOR as a 
supplement to their curricular activities. This program is laying the foundation for a long-term 
satellite construction program at MIT. The satellite is being designed as a part of AFRL’s 
University Nanosatellite Program, which provides the funding and a framework in which student 
satellite teams compete for a launch to orbit. To this end, the satellite must fit within an 
envelope of 50cmx50cmx60cm, have a mass of less than 50kg, and meet stringent structural and 
other requirements. In this framework, the CASTOR team successfully completed PDR in 
August 2009 and CDR in April 2010 and will compete at FCR (Flight Competition Review) in 
January 2011. The complexity of the project requires implementation of many systems 
engineering techniques which allow for development of CASTOR from conception through FCR 
and encompass the full design, fabrication, and testing process. 
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1 INTRODUCTION 


MIT’s Cathode/ Anode Satellite Thruster for Orbital Repositioning (CASTOR) is an orbital 
maneuver and transfer bus with the technical objective of achieving one kilometer per second of 
delta-V over a one year mission in Low Earth Orbit (LEO). This is accomplished using a novel 
electric propulsion system described below. As a technology demonstration mission, the success 
of CASTOR in LEO will pave the way for a modular bus design, which would provide small 
payloads with a low cost, high delta-V orbital transfer capability in support of the NASA ESMD 
exploration and technology development missions. CASTOR will serve as a technology 
demonstration of this concept and of the DCFT (Diverging Cusped-Field Thruster) under 
AFRL’s University Nanosatellite Program. 

1.1 UNP/CAPSTONE CLASS 


The UNP is a program jointly sponsored by the Air Force Research Laboratory's Space Vehicles 
Directorate (AFRL/RV), the Air Force Office of Scientific Research (AFOSR), and the 
American Institute of Aeronautics and Astronautics (AIAA) to educate and train the future 
workforce through a national student satellite design and fabrication competition. This program 
is held biannually, currently undergoing its sixth iteration. A major focus area of UNP is 
developing student's communication abilities of technical topics. Each student's communications 
abilities are challenged before beginning the program, as entry into this program requires a 
detailed proposal about the student's design, motivation, and reason for participation which 
follows the UNP guidelines. MIT undergraduate capstone students, under the guidance of Space 
Systems Laboratory (SSL) faculty and graduate students, successfully gained its first entry into 
this program in the winter of 2009. 

After being accepted, the team must begin iterating through design ideas. It is critical that the 
design and rational behind it are thoroughly documented as members are in flux and one cannot 
guarantee that the entire team will be able to remain with the design from conception to final 
product delivery (a 2 year period). Furthermore, this documentation is used on future satellite 
designs to ensure that mistakes are not repeated, granting the MIT Satellite Team continuity. 
Good documentation of the design goes beyond aiding the team, and is used as one of the 
primary methods of comparing competing university's designs and ensuring that predefined 
limitations are taken into consideration. Thus UNP ensures that students are not simply good at 
communicating ideas to others but also at processing others communications to them. 

UNP grants students the opportunity to refine their communication abilities during a series of 
documentation submittals and design presentations. Each university undergoes five major design 
reviews: system concept review, preliminary design review, critical design review, proto- 
qualification review, and flight competition review. During these reviews, the team's 
documentation of the design (including design documentation, risk matrix, safety procedures, 
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and requests for waivers), presentation about the design, and actual design itself are the primary 
aspects used to differentiate competing universities. Both the documentation and presentations 
are judged by a panel of experts. These experts provide feedback on the documentation and 
presentation to ensure that students develop their communications abilities. Thus the best design 
is not the guaranteed winner; the team that best communicates having a good design will win. 

1.2 MISSION OBJECTIVE 


The mission of CASTOR is to validate the performance and application of Diverging Cusped 
Field Thruster (DCFT) technology. This will be achieved by taking on-orbit state data to 
compare the degradation experienced by the DCFT to that of similar technologies. Mission 
objectives are: 

• Minimum Success: Demonstrate that the DCFT will operate on-orbit 

o Objective: Operate the DCFT on orbit for 1500 hours, which is comparable to 
similar technologies 

• Minimum Success: Use the DCFT to provide a measurable change in velocity 

o Objective: Measure the on-orbit performance, efficiency, and degradation of the 
DCFT during orbital maneuvers 

The success criteria of these mission objectives are: 

• DCFT Operation 

o Capture images of the DCFT as it thrusts. If the images show the plume is red, 
then the engine is not just venting Xenon 

o Show that the DCFT can transition from a standby heating mode to a full power 
operational mode 

• DCFT Characterization 

o Measure a noticeable change in velocity to show performance 

o Measure the velocity over equal increments to determine if the degradation of the 
DCFT effects the performance of the vehicle 

o Compare input power of the engine to the output thrust to show the efficiency of 
the engine 

o Capture images of the plume, showing the change in flame color, which dictates 
the degradation of the DCFT 

1.3 ESMD RELEVANCE 

The availability of a low-cost Orbital Transfer Vehicle that can reach the Moon, Lagrange 
Points, and beyond will enhance NASA’s capabilities for low-cost space exploration and 
scientific discovery. CASTOR serves as a key technology demonstration of this OTV capability 
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in its demonstration of almost 1 km/s of delta-V in its one-year mission, a high delta-V for a 
satellite its size. This provides the following capabilities for NASA ESMD: 

• A low-cost OTV with 2.0 km/sec of delta-V, or an upgraded CASTOR vehicle, would be 
able to depart GEO or GTO to carry small scientific payloads to lunar orbit (or impact) in 
support of lunar science. This would augment NASA’s program to return to the Moon 
with a low-cost robotic exploration capability. Furthermore, it could provide a Scout- 
class lunar mission capability financially accessible to universities. 

• Such an OTV could also depart GTO or GEO to travel to Lagrange Points where 
numerous astrophysical missions are envisioned to operate. One such mission is Stellar 
Imager (SI), a synthetic imaging mission that uses ultra-violet optics on multiple small, 
65 kg spacecraft to image exo-solar stellar disks. The process of synthetic imaging 
requires that these individual spacecraft be frequently maneuvered to different relative 
locations to fill the Fourier coverage of the image being synthesized. A derivative of the 
CASTOR design could fulfill the needs of this mission. Other possible roles at ESL2 
include inspection, repair, replenishment, and orbital maintenance of unstable Halo orbits 
of other astrophysical facilities. 

• Autonomous rendezvous, close-proximity operations and capture/docking are essential 
enablers for telescope servicing, robotic assembly, inspection, and sample capture (Mars 
and Lunar Sample Return). These are enabled by efficient propulsion systems. 

1.4 OVERVIEW OF SUBSYSTEMS 


The current architecture of each sub-team is as follows: 

• Structures: Four trusses mount around the propellant tank using three tank clamps. 
The ESPA (EELV Secondary Payload Adapter) ring mount attaches to the bottom of 
the trusses; two of the solar array panels are body-mounted directly to the trusses, and 
the other two solar panels mount to opposing trusses with a hinge. The solar arrays 
deploy using linear actuators that release pins in the panels. The structural 
configuration is shown in Figure 1. 
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FIGURE 1: STRUCTURAL CONFIGURATION 


• Thermal: The satellite is designed to sustain passive thermal control. Some 
components require surface treatments of Z93 in order to maintain operational 
temperatures. Temperature sensors will also be used to track the thermal state of the 
satellite to allow for active thermal control by increasing or decreasing power to 
certain units in response to unexpected temperatures. 

• Operations: The HETE ground station at Cayenne will be used. Pre-launch and 
launch operations are compiled in the Concept of Operations Document (ConOps). 
The on-orbit operations will be performed as follows: detumble, solar panel 
deployment, commissioning, system verification (standard orbit operations), 
decommissioning, and finally end of life via an uncontrolled re-entry. Orbital 
maneuvers will be performed in LEO to demonstrate high delta-v capability via 
orbital altitude changes. 

• ADCS: Attitude determination will be performed with 4 Sinclair sun sensors, 2 PNI 
Corporation 3-axis magnetometers, and a 3-axis gyro. Attitude control will be 
performed with 3 reaction wheel assemblies in each orthogonal thrust axis and 3 
torque coils in each orthogonal axis. GPS navigation will be used for GNC using a 
space-rated SSTL GPS receiver. Furthermore, a NORAD TLE is provided for free on 
a daily basis for a cross check. Furthermore, a magnet will be placed opposite the 
engine to cancel the engine dipole. 

• Avionics: The backbone of the avionics subsystem is 3 Microchip dsPIC33F 16-bit 
microcontrollers and a FLASH memory device. This is accompanied by all sensors 
and actuators while running FreeRTOS. 

• Communications: Two Microhard S-band modems will support two patch antennas 
to provide 1 1 5 Kbps data rate capability. 
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• Propulsion: A modified Hall thruster built in-house will operate in either high power 
mode, providing about 4 mN of thrust, or in off mode, in which the cathode will 
remain heated. The propulsion system will also consist of the tank and various 
plumbing components. The thruster will be mounted on the opposite end from the 
ESPA ring mount. Plumbing will be provided largely by a NASA-provided flow 
controller called the Xenon Feed System. 

• Power: Donated solar cells with an area of 1 . 1 m will provide a maximum of 160 W 
to the Maximum Peak Power Tracker, which will provide power to the various 
components as needed and to Nickel-Cadmium batteries for storage during eclipse. 
Furthermore, the custom Power Processing Unit (PPU) and Power Distribution Unit 
(PDU) will provide power to propulsion and all other systems, respectively. The solar 
panel configuration is shown in Figure 1. 

• Science and Payload: A camera pointed at the thruster plume will monitor the plume 
in order to measure engine health and thus efficiency throughout the mission. 

1.5 DELIVERABLES 


The CASTOR program has a series of deliverables, from hardware to documentation. 

By the end of the nanosatellite design and protoflight build phase, the program will have 
constructed a protoflight (protoqualification) nanosatellite and have participated in PDR, CDR, 
and PQR. Protoflight implies that the Flight Competition nanosatellite deliverable is a flight unit 
with full hardware traceability (vs. a non-flight Engineering Design Unit, or EDU). Specifically, 
this requires: 

• Protoflight Unit Nanosatellite: Experiment and support systems, including power to 
operate systems 

• Mechanical and electrical interfaces with the Lightband, on the nanosatellite side of the 
interface 

• Safety features/inhibits for nanosatellite-relatcd hazards 

• Ground handling and maintenance provisions for nanosats (mechanical and electrical) 

• Ground support equipment and related procedures 

• Operations (Ground, On-orbit) 

A series of documents is used to represent the current state of the satellite and serves as the 
documentation that is necessary to present at reviews and to potential customers. Furthermore, it 
provides an incremental status of the design at different levels of maturity. 

In order to maintain the documentation, it is necessary to implement a system of configuration 
control. Furthermore, this must be implemented in such a way that does not impose an excessive 
amount of documentation on the members of the CASTOR team. In general, configuration 
control systems require exorbitant amounts of paperwork to operate, so it is desired to find the 
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bare minimum of paperwork that is necessary to implement configuration control. This 
implementation is two-fold: (1) by placing incremental documentation that represents the state of 
the system at key points in the design process under the team’s fileshare and (2) by maintaining a 
system of Engineering Change Orders. 


TABLE 1: DOCUMENTATION SUMMARY 


Document/Model 

Development 

Phases 

Execution 

Phases 

Status 

Requirements Verification Matrix 
(RVM) 

A-B 

A-D 

85% 

Work Breakdown Structure (WBS) 

A 

B-E 

80% 

Program Schedule 

A-C 

A-E 

90% 

Budgets (MEL, Data, Power, 
Communications) 

A-C 

B-D 

85% 

CONOPS 

A-C 

D-E 

90% 

Risk Mitigation and Safety 

A-C 

D-E 

50% 

Integrated Systems Model 

A-E 

D-E 

90% 

Interface Control Documents 

B-C 

C-E 

85% 

CAD Models 

B-C 

C-E 

90% 

Systems Diagram 

B-D 

C-E 

25% 

Electrical Schematic Diagrams 

B-D 

D-E 

25% 

Manufacturing and Integration 
Plan 

B-D 

D-E 

70% 

Testing Plans and Reports 

B-D 

D-E 

75% 

Design Document 

B-D 

B-E 

95% 

On-Orbit Handbook 

D-E 

E 

10% 
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The first column represents the document that is being referenced. The second represents the 
phases in which the document is created and the third likewise represents the phases in which 
that document is executed and/or referenced. The final column represents the approximate status 
of completion of the document for the CASTOR program. The phases are defined according to 
the standard NASA system maturation process as shown below: 

• Phase A: Concept Development (completed with a System Requirements Review) 

• Phase B: Preliminary Design (completed with a Preliminary Design Review) 

• Phase C: Complete Design (completed with a Critical Design Review) 

• Phase D: Build and Test (completed with a Flight Readiness Review) 

• Phase E: Launch and Operations (Completed with end-of-mission) 

1.6 OUTLINE 


The remainder of this paper will: 

1 . Describe the system engineering process used in designing and testing CASTOR 

2. How critical technologies are incorporated into the design 

3. How the systems of the satellite are integrated together 

4. How the satellite is fabricated and tested 

Other tools that arc used in order to best design the satellite. 

2 SYSTEMS ENGINEERING PROCESS 


2.1 CASTOR MILESTONES & RESOURCES 


Throughout the CASTOR program there are multiple significant milestones which the systems 
team needs to prepare the entire team for. The following milestones give a sense of the type of 
work focused on during each phase of development as well as a general time reference for the 
CASTOR program. 

Program Milestones 

SCR - Systems Concept Review (March 2009 via Telecon) 

• Focuses on challenging basic requirements and design concepts to determine if the 
satellite’s mission is feasible. 

SRR - Systems Requirement Review (April 2009 via Telecon) 
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• Reviews the underlying system requirements which will be driving all the major design 
decisions for the satellite. 

• Makes sure that these top-level requirements will lead to the right design. 

PDR - Preliminary Design Review (August 2009, Logan, UT) 

• First thorough scrubbing of the design by UNP and NASA down to every subsystem 
level. 

• Based on recommendations from UNP and NASA, significant design changes were made 
after PDR. 

CDR - Critical Design Review (April 2010, MIT) 

• CDR was the major milestone this semester. 

• UNP review of a mature satellite design. CDR was more focused on assessing UNP 
confidence in our design as well as program management procedures. 

• PQR - Proto-Qualification Review (August 20 1 0, Logan, UT) 

• Focus is to display operable hardware to strengthen confidence in satellite design and 
program management 

FCR - Flight Competition Review (January 2011, Albuquerque, NM) 

• At FCR, each university will have a 1 5 minute presentation and then a hardware station 
afterwards and groups of judges will evaluate the final design and choose the winner. 

CASTOR Satellite 



Battery Box 
Fixed Solar Arrays 


DC FT 

Avionics/Power Boxes 


Patch Antenna 

ESPA Mount 


Reaction Wheel 


Deployable 
Solar Arrays 


FIGURE 2: CASTOR SATELLITE 
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Significant design changes were made from PDR to CDR such as the deployable solar panels as 
well as the light band interface. This can be seen through the differences in this PDR layout vs. 
the CDR layout. 



Light Band Interface 


DCFT 


Xenon Tank 


Comm Antenna 


Nitrogen Thrusters 


FIGURE 3: PAST DESIGN ITERATIONS 


2.1.1 INPUTS & OUTPUTS 

Identification of goals, in terms of inputs and outputs gives direction to the CASTOR project and 
helps to define the boundaries for achieving objectives. Primary inputs and outputs are outlined 
below: 

Inputs: 

• Personnel (undergraduate students, graduates, faculty mentors, and undergraduate 
researchers) 

• Facilities 

• Donors & Partners 

Outputs: 

• Proto-flight satellite (with supporting documentation and ground support) by January 
20 1 1 for Flight Competition Review 
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2 2 REQUIREMENTS ANALYSIS/VALIDATION 


CASTOR’S requirements stem from a couple of different sources such as flowdown, interfacing, 
and UNP guidelines Flowdown requirements come from the mission and system requirements 
meaning that these are needed in order to meet the mission statement Another source for 
requirements is interfacing, which is needed to ensure that everything interfaces correctly The 
CASTOR team also needs to make sure that they comply with the UNP guidelines 

The mission requirements are stated as follows 

• Measure the on-orbit performance, efficiency, and degradation of the DCFT during 
orbital maneuvers 

• Operate the DCFT on orbit for 1500 hours 

The system requirements are flowdown requirements from these and are stated as follows 

• CASTOR shall have a DCFT as the primary propulsion system, which shall operate 
throughout the mission lifetime 

• The CASTOR bus must be able to support on-orbit mission operations for the mission 
lifetime of at least 6 months 

• CASTOR shall provide sufficient state data to measure the change of performance, 
efficiency, and degradation over the DCFT's operational lifetime 


Each subsystem has requirements that flowdown from these system requirements 

In addition to stating each of the requirements, the spreadsheet lists the document that shows 
how that requirement was met and the test that verified it was met For instance, the 
requirement “EPS must be able to generate 113 7W in a fully operational state” is met m the 
Design Documentation and tested in the solar panel test 

The RVM has all of the requirements listed and each of these requirements is met through the 
design All of the requirements have a verification document listed, and if applicable the 
appropriate test is listed (Appendix 9 1) 

2 2 1 RELIABILITY, SURVIVABILITY AND PRODUCTION 

An overarching objective of the CASTOR program is to produce a reliable satellite that can 
survive launch and operate in orbit To this end, requirements flow down to the various 
subsystems to meet these mission objectives Survival goals generally correlate with UNP 
requirements which stem from well-margined launch requirements For compliance with these 
requirements, CASTOR must survive 20 G forces in all directions, and have a lowest natural 
frequency above 100Hz Ensuring that the CASTOR structure can meet these restrictions, and 
do so reliably, requires careful design and planning 
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Often the best way to see if a design works is to build it The structure alone has undergone at 
least some redesign after each time it was built Learning how to design parts that are easy to 
assemble and manufacture is key to creating a simple design By having students build what 
they design, students can identify what aspects need improvement For instance, using a 
standard set of screw sizes is important so as to reduce lead time on ordering parts and tools It 
also allows for interchangeability of wrenches and such which makes facilitates building 


2 22 SAFETY 

From a human factors and safety standpoint, the safety of personnel involved in all stages of 
design through operations is of paramount importance With safety in mind, conservative 
choices are made throughout the design process to lead to the generation of a product that is safe 
to operate Designs are required to meet certain safety guidelines outlined by UNP In the 
laboratory, various precautions are strictly followed Students are not allowed to work by 
themselves in certain laboratory environments, and are required to take a special safety class 
designed for engineering students m the department before accessing the laboratories Only 
students who have taken a four-hour machme-shop training session are allowed into the Gelb 
machine shop to manufacture parts on the mills, lathes and waterjet 


22 3 TRANSPORTABILITY 

Since ultimately CASTOR shall be launched from a location far from MIT, transportation and 
ground support equipment are under consideration Weighing concerns between transportation 
of a highly pressurized xenon tank with risk associated with having students assembling the 
satellite around a pressurized tank, the former was chosen Modifications were made to the 
design to allow insertion of the tank after the majority of assembly had taken place, thus 
allowing the separate transport of satellite and pressurized tank to the launch site Ground 
support equipment, including a carrying case for the 50kg satellite, is currently under design 


2 3 FUNCTIONAL ANALYSIS AND ALLOCATION 


The general approach to CASTOR is to break the system down into manageable subsystems An 
outline of the CASTOR system using Product Breakdown Structure (PBS) is shown m Figure 4 
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FIGURE 4: PBS FOR CASTOR PRIMARY SYSTEM 


The primary responsibilities of these subsystems are described in Table 2. 

TABLE 2: CHARACTERIZATION OF SUBSYSTEMS 


Subsystem 

Primary Responsibilities 

Avionics 

Provide computing control for CASTOR 

Communications 

Communicate data & telemetry back to ground 
station and upload commands to CASTOR 

ADCS/GNC 

Attitude and control for positioning CASTOR 

Science & Payload 

Camera for monitoring thruster performance 

Structures 

Structure to interface with all other subsystems 
and launch vehicle 


Solar Panel Deployment capability 

Thermal 

Provide thermal control for CASTOR 
including all components 

Power 

Provide power to CASTOR subsystems 

Propulsion 

Design and operation of thruster 


Additional aspects of the CASTOR system include the concept of operations, including the 
ground station (both at MIT and through HETE-2 at Cayenne), and interfacing with the launch 
vehicle. Since the primary path to launch involves winning the UNP competition and thus being 
provided with a launch as well as an ESPA ring interface, focus on launch accommodations will 
be a much later stage in the program. As our primary payload is the propulsion system, with the 
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camera as a monitoring device, the CASTOR vehicle is its own payload, and thus separation of 
craft and payload is unnecessary. 

Since CASTOR requirements indicate that thruster degradation and performance must be 
measured, a long mission of approximately one year is envisioned. A useful analysis tool for 
developing this mission is to use a Functional Flow Block Diagram (FFBD) to describe the 
mission over time. The FFBD in Figure 5 shows the top level mission plan from a concept of 
operations perspective, and works down into more detailed levels of operation for the on-orbit 
deployment stage, the commissioning stage, and the normal operations stage. 


TOP LEVEL 



SECOND LEVEL 



FIGURE 5: FFBD OF MISSION CONOPS 


The normal operations stage shows iteration, in that the mission continues to cycle through 
sunlight and eclipse every 90 minutes, until the satellite ceases for function properly. Only at 
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this point in time is the satellite decommissioned for destructive re-entry into the Earth’s 
atmosphere. 


2.4 SYNTHESIS 


2.4. 1 COTS VS. CUSTOM (DEVELOPMENT ITEMS) 

Commercial Off-The-Shelf (COTS) items have become of increasing interest as space-qualified 
components reach the open market. These arc defined as items which can be purchased as a unit, 
in quantity (inferring the availability of identical units), and are generally supported by a vendor 
and operated without requiring knowledge of the inner workings of the component. COTS 
components are common in CASTOR. Non-Developmental Items (NDI) are not used in 
CASTOR, due to the program’s non-governmental nature. Developmental items (DI), or those 
items custom-designed for CASTOR, are found throughout the project. 

Key design tradeoffs exist between COTS and custom items that must be balanced from the 
program level down to the component level. These decisions can drastically affect operations 
and integration down the road, and thus must be considered in detail. Tradeoffs between COTS 
and DI components are outlined in Table 3. 


TABLE 3: COTS VS. DI TRADEOFFS 


COTS 

Developmental Item 

Pros 

• Requires fewer student resources 

• Flexibility to design to specific 


(less time) 

needs 


• On-demand spares and 

• Compatible with system - easy to 


replacements 

test and integrate 


• Need not re-invent wheel 

• Often less expensive than 


• Degree of quality 

purchasing space-qualified 



components 

Cons 

• Testing/reliability/compatibility 

• Ties up resources (student time) 


issues 

• Students may not have experience 


• Black-box product (no control over 

to achieve quality of equivalent 


product or little transparency) 

COTS component 


• Expensive (sometimes) 

• No space heritage 


• May not be space-qualified 



Time and money are two of the biggest factors which influence design choices to implement 
COTS or DI components. While DI components initially may seem cheaper, in reality student 
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time is not free. The opportunity cost of that student’s labor working on furthering the design of 
another system must be considered. Some COTS components are also more reliable, and some 
are also inexpensive. 

A summary of key COTS and custom components is shown below in Table 4. 


TABLE 4: COTS/DI COMPONENTS 


Component 

COTS/DI 

Reasoning 

Cathode/Anode 

Thruster 

DI 

Mission Requirement 

Solar Panel 

Deployment 

Mechanism 

COTS linear actuator 
DI release hinge 

Reliability of deployment is essential, as well as 
non-deployment during launch, thus COTS linear 
actuator provides reliability, while DI release 
hinge provides interface to CASTOR system 

Reaction Wheels 

COTS 

Perceived as more accurate & sturdy than student- 
built RW; Requires less student time, though 
expensive 

Camera 

COTS camera 
DI casing 

Camera is inexpensive, however must extensively 
test to ensure space-qualification & survival in 
thrusting environment; Requires modification (DI 
casing) to reduce negative impact of thruster 
plume on lens 

Sun sensors 

COTS 

Meets system requirements without increasing 
student workload or going over budget 


2.4.2 REUSE 

Reuse of previous designs, and applying lessons learned from them allows for the development 
of an improved system. Graduate students who participated in the FalconSat program as part of 
their undergraduate curriculum have been able to contribute lessons learned to members of 
CASTOR. Experienced team members who have contributed over the life of the project are also 
valuable to the CASTOR program. 
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Since the CASTOR mission involves destructive re-entry as a decommissioning procedure, reuse 
of the vehicle itself is not planned. However, CASTOR designs shall be well-documented in 
order that future satellite designers can utilize them. Heritage components, such as the GPS, sun 
sensors, magnetometer, linear actuators, and reaction wheels, have all been flown in space 
previously. Using heritage components gives more confidence in the reliability of the design. 

Facilities 

Members of CASTOR have access to a number of facilities. Outlined in Figure 6, the potential 
of each facility should be realized, and can be used for multiple purposes. 


CASTOR Facilities 



FIGURE 6: FACILITIES 


2.5 SYSTEMS ANALYSIS AND CONTROL 


2.5.1 TRADES 


During the design process the sub-teams often have multiple options as far as components or 
methods to use when fulfilling the requirements. In order to determine which option is best, it is 
necessary to perform a trade study. By identifying the problem, brainstorming different 
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solutions, assessing important criteria, and then comparing the various designs by these criteria 
and their importance, a design decision is achieved. Numerous trade studies have been 
performed over the course of the project. Here is an example to demonstrate the methodology 
with which design decisions are approached. 

Trade Study Example 

Background: Linear Actuator vs. Solenoid for the Solar Panel Release Mechanism 

Originally, the SPRM was planned to be driven by a pull-type solenoid, not a linear 
actuator. A solenoid would be very similar in function to a linear actuator: once current 
flows to the solenoid, it would retract its solenoid pin, just like the linear actuator. In fact, 
solenoids arc often used for one-time releases like this application. Solenoids are simpler 
- and therefore more reliable - than linear actuators, and usually much less expensive. 

However, a linear actuator offers distinct advantages over a solenoid. For one, linear 
actuators can be more mass efficient than solenoids of similar sizes. In addition, a linear 
actuator exerts a relatively constant force throughout its stroke, whereas the force a 
solenoid exerts on its pin is proportional to the fraction of the pin inside the solenoid. 
This is especially important to consider, given that for this application, the maximum 
force is needed in the beginning at the largest extension of the pin. 

But by far the most significant advantage of a motorized linear actuator over a solenoid is 
the fact that the motion of the solenoid’s pin cannot as easily be constrained before 
release. The linear actuator’s pin is often held in place with a stiff mechanical locking 
system, whereas solenoid pins are generally held in place with springs and can therefore 
move more easily during launch. Because of this problem, using a solenoid increases the 
risk of premature deployment of the solar panels and failure of the SPRM. 

For these reasons, a motorized linear actuator will be used instead of a solenoid. 

The chart below, similar to a Pugh chart, is the type of trade comparison done which was 
described in the paragraphs above. The characteristics of the component are listed as well as the 
level of importance of each characteristic. Then the components are compared on each category 
on a scale from 1 to 5, 5 being preferred. In this case the linear actuator was chosen over the 
solenoid because it performed better in the driving category of minimizing risk, and the total 
score took importance weighting into account. Even though the solenoid was cheaper, simpler 
and more reliable, it did not have the same level of safety which is most important when 
preventing premature panel deployment during launch. 
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Characteristic 

Importance 

Solenoid Rank 

Linear Actuator Rank 

Simplicity 

Med 

4 

3 

Cost 

Low 

3 

2 

Reliability 

Med 

5 

4 

Mass 

Med 

2 

4 

Risk 

(Premature 

Deployment) 

High 

2 

5 

TOTAL 


31 

39 


2.5.2 RISK MANAGEMENT 


In order to mitigate risk, potential difficulties must be identified, quantified, tracked and 
analyzed. A risk tracking spreadsheet (see Appendix 9.4) serves as the backbone of CASTOR’s 
risk management system. These require continuous monitoring and thorough analysis for the 
purpose of risk reduction. 


2.5.2. 1 D EFINI NG RISK 

Risk: The inability to achieve mission objectives - comprised of failure probability and 
consequences [1], 

There are several types of risk. In order to consider them, a careful definition was determined by 
consulting NASA, Air Force, and MIT documentation [1,4]. Programmatic risk consists of any 
risk involving the program, including all external and internal risk. Subsets of programmatic risk 
include technical risk, cost risk, and schedule risk. Tradeoffs between the types of risk constitute 
risk management. Risks differ from issues in that they are problems that have not yet occurred. 
Once a risk becomes a reality, it is an issue and requires immediate action. 

Successful risk management comes from continuous work. In order to mitigate risk, careful 
identification, analysis and tracking must be completed to ensure safety. 

The management process can be broken into stages: 

1) Planning 

2) Assessment 

3) Handling 
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4) Monitoring 


Risk planning involves creating a framework to identify and track risks, along with their 
mitigation strategies. Documentation, such as the risk management file in Appendix 0, falls 
under this category. Planning also includes scheduled meetings with team leads to discuss risks. 

Assessment consists of the actual identification and analysis of risks, including their likelihood 
and perceived consequence. Assessments are generally conducted by subsystem personnel, at 
the request of risk management managers. Updating the documentation created in the planning 
stage is a part of assessment. 

Risk handling is the response to risk assessment. It involves distribution of responsibility of risk 
mitigation, to team leads for instances, as well as a plan forward to reduce or respond to risks. 
Higher risk items shall be brought to the attention of everyone in the systems team to increase 
involvement. 

Finally, risk monitoring is the process by which the entire system risk is checked, allowing for a 
comparison to metrics to show improvement. This allows one to see the effectiveness of risk 
handling measures. For CASTOR, the current metric is ‘risk level,’ measured as a function of 
likelihood and consequence. Each risk item receives a score from 1 -5 for both likelihood and 
severity of consequence (5 being extremely likely or catastrophic). Risks are considered 
improved as risks decrease in levels. 
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FIGURE 7: RISK LEVEL - LIKELIHOOD VS. CONSEQUENCE 

The above chart depicts the five levels of likelihood and risk, and shows the breakdown into risk 
level. Green indicates low risk, yellow medium risk, and red shows high risk. By this point in 
the design, there should be no high risk items, as risk items should flow in the direction of the 
arrow. Monitoring helps in tracking this flow. 
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2 . 52.2 APPROACH 


By improving CASTOR’s management process, risk shall be reduced. The implemented system 
includes a tracking spreadsheet and a process of listing components and their technical risks. 
The last person to update the item is also tracked in the system. 

An initial project-wide risk assessment was completed to determine where components stand and 
what areas needed additional focus. This involved contacting leaders of each subsystem and 
discussing risks and mitigation strategies. Next, further progress was made by discussing the list 
of risks with team leads to increase the robustness of the spreadsheet. 

Further enhancement of the risk management spreadsheet is an ongoing process. Care must be 
taken not to overload the process by delving too deeply into compounded problems 
(combinations of failures), and to focus on the most critical risks. While initially adding risks to 
the database was encouraged, feedback from CDR showed that risks should be limited to twenty 
or thirty important risks, rather than nearly a hundred detailed risks. Thus the database is 
undergoing reduction to produce a more condensed form that brings focus to the true concerns 
for the project. 


2522 ~ ASSESSMENT MODEL 

Various characteristics of risk should be tracked to gain a sense of risks. These include the area 
of risk (hardware, software, operational, programmatic, manufacture, transport, etc.), the risk 
dependency (what else must fail first), likelihood, consequence, mitigation, diagnostic, and repair 
or backup method. Subsystems are asked to self-report estimates of their risks and address these 
categories. In considering risks, personnel should be aware that critical changes that affect 
multiple systems can have far-reaching effects. These can cause other subsystems to make 
numerous changes to their system and thus increases risk level. Since the level of risk is 
measured by the likelihood and consequence, changes such as this increase the consequence 
level and thus are reflected in the tracking process. 

Relationships between risks are shown as ‘dependencies.’ Direct links between subsystems can 
lead to similar probabilities, and a simplification of risk tracking. 

Consistency is somewhat maintained between subsystems, as team members updating the 
spreadsheet are asked to consider the following scheme: 


TABLE 5: RISK LEVELS LEGEND 

Level 

Likelihood 

Consequence 

1 

« 1% 

Inconvenience 
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2 

~1% 

Causes difficulties/delays, but can be corrected or dealt with 

3 

-10% 

Compromises mission 

4 

-25% 

Mission Failure or Partial Mission Failure 

5 

-50% 

Injures people or harms launch vehicle & payloads; 
Total Mission Failure 


Further work should involve tracking the assurance level of the evaluator (whether this is a tested 
likelihood or a complete guess). 


2.5.2A TECHN IC AL RISK _ 

Currently all teams have updated the risk assessment spreadsheet. Some teams failed to fill in all 
requested information, and work is being conducted to track down answers to these missing 
pieces. Each item is looked at individually and considered for thoroughness. Higher risk items 
are initially flagged so as to prioritize them. Currently higher-risk items (level six or seven) 
include the anode (high voltage affecting system), and camera lens degradation. The next set of 
high risk items includes magnetometer failure, schedule slips, reaction wheel malfunctions, 
torque coil failures, solar panel deployment failure, and others. Mitigation strategies range from 
using the engine to de-saturate to modifying the duty cycle to account for low power input. 

Meetings with subsystem team members can provide additional insight into potential risks. A 
meeting with the Power team took place to discover the relationship between power and voltage 
converter failures and various components. A single converter failure could cause an entire 
system, for instance ADCS, to become inoperable. Since most ADCS components work on 5V 
power, only the torque coils will operate should there be a failure. Thus analysis of the 
discussion also led to the discovery of unlisted risks, such as inhibits, and the difference between 
the battery charging circuit and the MPPT. Careful checking must be conducted to avoid errors, 
and to discover relationships between failures. 

2. 5.2.5 CO ST E STIMATE 

Assessment of costs is more straightforward, in that spending has been tracked over the last year 
and a spreadsheet has been implemented to track expenditures. Details regarding expenditures 
are tracked. Income, or available funds, is constrained, and shall be determined based on a 
detailed cost projection plan (see Appendix 9.3). The current method for dealing with this 
limitation is to delay the purchase of expensive, high TRL components, and instead test with 
engineering mockups until funding can be secured. It has been noted that for FCR in January, 
does not expect a flight-ready satellite, but a proto-flight satellite. Instead, high-cost flight 
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hardware can be purchased later, as long as the interfaces and controllability can be modeled. 
For instance, purchase of one reaction wheel and a demonstration of functionality will suffice, 
rather than purchasing (and integrating) all three reaction wheels. Functionality of the other two 
reaction wheel should be verified by integrating engineering models into the system. This 
provides the advantage of reduced cost as well as sufficient testing. 


Summary of Cost Risks: 

- Limited Budget 

o Consequence: students spend excessive amounts of time re-creating COTS 
components to reduce costs; adverse effect on schedule adherence 

o Dependent on stringent monetary control and limited donations 

o Mitigation: Ask companies for material donations (such as solar cells) to reduce 
costs while not impacting student workload 

Exceeding budget 

o Consequence: Strain on resources; could lead to lack of funding for testing and 
manufacture of satellite, as well as purchase of components 

o Dependant on insufficient tracking and spending policies; inability to accurately 
project costs 

o Mitigation: include margining in cost projections; outline of all large-cost items & 
cost estimates; delay purchase of expensive items until funding is secured; test 
with less costly ‘engineering units’ 

Lack of funding for testing and manufacture of satellite 

o Consequence: serious delays which will adversely affect progress along UNP 
schedule 

o Dependencies: insufficient funds (lack of donors); going over budget 

o Mitigation: Promote satellite to potential donors; careful not to drastically exceed 
budget 

Other methods for dealing with cost risk that are already under implementation include cost 
margining and purchasing restrictions. Costly items must be approved by faculty and staff. 
Garrett Fritz has done some work on cost projection modeling for the future of the program. 


MIT CASTOR NASA ESMD Paper 


Page 27 


2. 5. 2. 6 SCHEDULE RISK 


Throughout the project great attention has been given to compiling schedules from teams and 
integrating them with a systems master schedule. Freeze dates have been created to help track 
design phases and keep teams at the same stage in design. Essentially the chosen method for 
reducing schedule-slip risk involves early identification of slips, re-working of schedule to 
reflect realistic delays (and flow-down to other systems), and reallocation of labor and resources 
to meet changing demands. Margins in the schedule allow for improved schedule-tracking, 
along with advanced freeze dates and compilation deadlines. Sub-teams are additionally 
encouraged to adhere to the schedule by taking part in schedule creation and thus being held 
responsible. Additional information on schedule can be found in Appendix 9.5. 


TABLE 6: SCHEDULE ITEMS OUTLINE 


Item 

Risk Level 
(low/med/high) 

Design Document Draft (4/23) 

Low 

Integrate Power w/Avionics 

Med 

(4/29) 


Design GSE (5/7) 

Low 

PPU Testing (5/7) 

Med 


2.5.3 BUDGET MANAGEMENT 


The Systems team also tracks the purchase orders that are submitted to the professor and is 
responsible for ordering components and updates the MEL part status to “delivered”. 
Additionally, a systems team member must approve all purchases before submission to the 
professor. Purchases are approved only if the component is listed on the MEL. This provides a 
method of cross-checking to avoid unnecessary purchases. 

The accrued costs of all purchased items are being tracked, not just those of flight hardware. An 
item is added to the spending tracking sheet once the purchase order has been approved, not 
when the actual debt has been incurred. This allows the team to anticipate the need to request 
more funding in a timely manner, should it become necessary. The Systems team must approve 
purchase orders in order to prevent unauthorized purchases. A student who wishes to purchase 
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hardware must completely fill out a standardized Purchase Order or PO form. This PO is then 
checked on the MEL to verify the part is accounted for. If it is, then the PO is submitted to the 
purchasing professor for ordering. If the part is not accounted for in the MEL, then it must first 
be submitted for approval to the MEL before being approved for purchase. If it is subsequently 
added to the MEL, the PO will then be accepted. 

This past March each sub-team provided a list of components that still need to be purchased 
before FCR next January. An estimated $101,108.64 of hardware and test expenditures is 
anticipated through FCR. A more short-term cost projection can be found in Appendix 9.3. 


2.5.4 INTERFACE MANAGEMENT 

Given the complexity of the CASTOR system, interface control documents (ICDs) are used to 
assist in modeling interfaces to ease integration efforts. The purpose of an ICD is to document 
and explain all of the possible inputs to and all potential outputs from a system or subsystem. 
This documentation is helpful not only for the future user of the system, but also for each sub- 
team designing the system. These documents help the designers determine what information 
they need to request from each team as well as how their design changes may affect the other 
teams. 


Below is a template for the MIT format ICD as well as explanations for each component. 
Formatting is often times just as important as the technical content because improper formatting 
can easily make the technical message confusing or completely not interpretable. 



The signature page 
needs to have the names 
of key persons relevant 
to this document. 

These people may be the 
relevant subsystem team 
leads, systems lead, 
chief engineer, etc. 
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Make sure the table of 
contents is correct. 

ICDs are updated 
frequently and pages are 
constantly shifting. 

List all of the figures 
and tables as well as 
their locations for quick - 
reference 

While ICD is being 
created there will be 
many TBR and TBDs 
during the system 

design process. 

Explicitly document 
these so that they will 
not be overlooked later 
on. 


The specific sections of 
the ICD will be different 
for each type of 
subsystem. For 
example, avionics will 
have a section for 
Software Protocol while 
the Structures team 
would have no need for 
that section 
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The Scope section 
should be a relatively 
short description of 
what systems this ICD 
covers 

Applicable Documents 
are important to point 
out especially if the 
expected audience is not 
familiar with them or do 
not have explicit access 
to the reference 
documents 

ICD block diagrams 
should be an extremely 
simple, non-technical 
diagram which 
eliminates any 
ambiguity about what 
system interfaces are 
being discussed. 


Make sure to define all 
acronyms. Assume that 
the reader does not 
know any of them. 

Here is an opportunity 
to add more diagrams, 
notes, etc. to help define 
the scope of this ICD in 
more detail. 

Document all changes 
so that everyone 
working on the ICD 
knows who has made 
the change and when. 


ICD Management 

Storage: The ICDs which are available for editing by the sub-teams are stored in the CASTOR 
fileshare. This is where the sub-teams can view their ICDs and make changes as they see fit. 
When the sub-teams want to submit these changed ICDs for approval they send them to their 
systems team liaison. The systems teams performs an initial screening of the ICDs and also 
passes them on to TAs who can point out any missed mistakes. Once the inconsistencies have 
been fixed, the ICDs are then placed in the UNP section under 4.2.4. 2-Documenation-ICDs 
which will eventually be submitted to UNP. 
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Subteam edits Systems Graduate TAs provide 

ICD Reviews ICD feedback on ICD 



Systems 
commits ICD 
to fileshare 


FIGURE 8: ICD REVIEW PROCESS 


Tracking Changes: When an ICD is edited the author needs to list the date 
the topic of change in the “Revision History” section of the ICD itself, 
document is reviewed, any questions can be directed to the original author, 
and speed of the ICD change approval process. 

Types of ICDs 

The Mechanical ICD identifies the hardware for the system or subsystem, and identifies to what 
it will be connected. For each piece of hardware, the ICD contains three main subsections: ICD 
Block Diagram, Physical Envelopes, and Hardware Mounting. The ICD Block Diagram 
identifies and shows all critical interfaces for the item. The Physical Envelopes section gives the 
initial (and, if applicable, final) current best estimate dimensions of the item: length, width, 
height, volume, and mass. The Hardware Mounting section provides a CAD drawing (if 
applicable) of each item, and describes the surface location, the hole locations, and the mounting 
hardware to be used. For many pieces of hardware, a fourth subsection, modeling, is included; 
this section describes any analysis (e.g. CAD drawings, finite element analysis) that was used. 

The Power ICD identifies the hardware necessary to power each system or subsystem, and 
identifies to what the hardware will be connected. The ICD contains four subsections: ICD Block 
Diagram, Connector Pin Out/In Matrix, Grounding, and Load. The ICD Block Diagram 
identifies and shows all interfaces and connections for the hardware. The Connector Pin Out/In 
Matrix lists the in and out pins used for each connection, as well as the amount of amperage 
passing through the connections. Diagrams of the pin connections are included. The Grounding 
section identifies the type of grounding connections (i.e. analog, digital, or both). The Load 
section identifies the amount of power each piece of hardware will receive during the mission, 
and how often the power will be received. 


of change as well as 
This way, when the 
This facilitates ease 
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The Thermal ICD identifies the surface connections (i.e. metal on metal contact) for each system 
or subsystem. The ICD contains four subsections: ICD Block Diagram, Heat Transfer Method, 
Thermal Path, Heat Loads and Fluxes, and Modeling. The ICD Block Diagram identifies the 
connections between the surfaces. The Heat Transfer Method section defines the method of heat 
transfer that will take place, the Thermal Path section identifies the path the heat load will travel, 
and the Heat Loads and Fluxes section identifies the amount of heat load that will be transferred 
during the mission, as well as the hardware limits. The Modeling section lists the types of 
analyses used. 

The Data ICD identifies the hardware for each subsystem and to what it will be connected. For 
each piece of hardware, the ICD contains four sections: ICD Block Diagram, Connector Pin 
Out/In Matrix, Software Protocol, and Data Load. The ICD Block Diagram shows all interfaces 
and connections between the hardware. The Connector Pin Out/In Matrix lists the physical pin or 
socket connections for each piece of hardware, and whether the connection is in or out, as well as 
the voltage and amperage of each connection. The Software Protocol section describes how the 
software will interact with the hardware, and the Data Load section lists the type and amount of 
data that will flow between the hardware, and how often, during the mission. 

Interface Diagram 

The following diagram provides a visual representation of the relationships between all of the 
sub-teams and the subsequent ICDs which need to be managed for each relationship. 


Pre-Launch Interface Diagram 



FIGURE 9: INTERFACES DIAGRAM 
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2 5 5 DATA MANAGEMENT 


All of the CASTOR Command Media is stored on a subversion repository which is broken down 
as follows 

• Management 

• Systems 

• Subteams 

• Shared 

Each of these sections has different levels of access Sub-team folders, for example, offer space 
for each of the systems to work on their command media before submitting it to systems for 
approval The systems team then makes the determination of whether or not that document is 
ready for submission to UNP Those final documents are then stored in a systems level folder 

The structure of the repository prevents multiple editors from overwriting changes if they are 
working on a document at the same time If there is a conflicted copy then the repository will 
advise the author to update to the newest version before submitting their changes 

CASTOR Design Document 

The CASTOR design document provides detailed descriptions for all aspects of the design 
process for each sub-team It explains both the technical concepts, team organization and 
development processes for everything including design, schedule, budget, scope, testing, 
manufacturing, etc This document will be compiled at the end of the semester and will provide 
both a work history for the semester and a sense of the current status and future work which 
needs to be done Transitioning a project between one group of engineers and another allows 
presents a challenge, one which CASTOR faces each semester, as information regarding design 
decisions can be lost and experts are replaced with novices The design document attempts to 
mitigate these transition difficulties, by providing a means of passing design information to new 
members and thus helps with project continuity 

Engineering Change Orders 

An Engineering Change Order (ECO) is the documentation process followed to implement 
significant changes that affect multiple subsystems Its purpose is to ensure continuity of design 
and to resolve potential conflicts which may arise from the design changes The ECO creation 
process serves as a mmi-review for significant changes so that all the sub-teams are on the same 
page This process is to 

o Deliver the proposed ECO to all directly affected subsystems for review 
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o Subsystems change specifics and inform the systems team 

o Deliver the current proposed ECO to all other teams for review 

o Check with systems team again 

o Perform a sign-off of the ECO at a team leads meeting 

This process managed by “ECO Manager” member of Systems Team who is responsible for 
making sure that all relevant parties are committed to the new design change before it is signed 
off. There have been six ECOs throughout the CASTOR program and there have been none so 
far this semester. However, the process is still in place in case significant changes still need to 
be made. 


MIT CASTOR NASA ESMD Paper 


Page 34 


• 

CASTOR 

ENGINEERING CHANGE ORDER 

ECO# 

002 

Originator 1 Date Submitted 

ECO Status 

Revision 

R. McLinko |2009/11/03 

Submitted 

01 

Changing Elements 

ADCS System Design 

Reason For Chanqe 

ystem has been shown to be inadequate to correct for disturbance torques throughout the 
lite. Furthermore, it is much header and more complicated than other options. 

The current nitrogen gas s 
operational life of the sate 

Description of Change 

lange are as follows: 
of the satellite is remold 

added to the satellite, orthogonal to the existing one 
Jed to the satellite in mutually orthogonal directions 
to "tumble" during eclipse 
is removed 
ite the structure 

wheels will be used to replace the engine gimbal system 

The key elements of the c 
-The nitrogen gas system 
-Two reaction wheels are 
-Three torque coils are adc 
-The spacecraft is allowed 
-The engine gimbal systen 
-A magnet is added oppos 
-The magnet and reaction 

ECO Board Members 

Signature 

Date 

Comments 

ECO Manager 




Operations Lead 




ADCS Lead 




Agonies Lead 




Communications Lead 




Propulsion Lead 




Power Lead 




Thermal Lead 




Structures Lead 




ECO Manaqer Notes 





FIGURE 10: SAMPLE ENGINEERING CHANGE ORDER (ECO) 
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2 5 6 MASS MANAGEMENT (MEL) 


The mass budget for CASTOR is tracked through the use of the Master Equipment List or MEL 
This list is an Excel Spreadsheet documenting components either on the flight model of the 
satellite or used for testing It also tracks components that still need to be acquired 

Each sub-team has a dedicated section of the MEL Through regular meetings with Systems and 
the team leads, the MEL is always an up to date representation of the components on the 
satellite When any component is updated on the MEL the person responsible for the change 
will document his name and the date onto that component’s row so that others can verify the 
change in the future Each team can use the MEL to identify particular part numbers or types of 
components used by other teams should they need to interface with them in their designs 

The MEL has the ability to hold mass margins for every component listed The margining 
scheme is 

Exact (0-5%) 

Mass component has been weighed and integrated into the satellite 
Fine Estimate (5%-10%) 

The mass has been quoted by the manufacturer or found on a specification sheet 
Coarse Estimate (15% - 35%) 

Number based on SMAD or other approximation not yet verified by 
manufacturer 

Guess (35% +) 

The component is still largely unknown, such as bolts/nuts in the current design 
2 5 7 TECHNICAL PERFORMANCE 

One important aspect of system control involves quantifying technical performance of 
components In order to measure progress and identify system weaknesses, tracking of the 
Technological Readiness Level (TRL) of components was implemented Before design freezes, 
as well as at various scheduled times in the program, each item is reviewed to assess its TRL, 
based on the NASA TRL chart shown in Figure 1 1 
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System test, launch, 
and operations 


System/subsystem 

development 


Technology 

demonstration 


Technology 

development 


Research to prove 
feasibility 


Basic technology 
research 



Actual system "flight proven" through successful 
mission operations 

Actual system completed and "flight qualified"through 
test and demonstration (ground or flight) 

System prototype demonstration in a 
target/space environment 


System/subsystem model or prototype demonstration 
in a relevant environment (ground or space) 


Component and/or breadboard validation in relevant 
environment 


Component and/or breadboard validation in laboratory 
environment 


Analytical and experimental critical function and/or 
characteristic proof-of-concept 


Technology concept and/or application formulated 


Basic principles observed and reported 


FIGURE 11: NASA TECHNOLOGICAL READINESS LEVEL ASSESSMENT TOOL (1) 


Since most CASTOR components have no space heritage, a TRL of 6 is the upper bound for 
qualification and the target for systems leading to FCR. Listing the TRL of the critical 
components (Table 7) provides a technical overview of the CASTOR system. 
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TABLE 7: CRITICAL COMPONENTS TRL 


Component 

TRL 

Sun Sensors 

9 

Reaction Wheels 

9 

PIC Communications 

5 

Thruster 

5 

Power Processing Unit (PPU) 

4 

Antenna 

3 

Camera 

3 


TRL incorporates the testing of the component into a metric. For instance, taking a system and 
putting it through thermal vacuum chamber testing might increase the TRL of the system, should 
it perform as expected. Should an item fail a test, it also fails to move up the TRL scale until the 
root of the problem is corrected. By monitoring both the TRL and the risk level of a component, 
efforts can be focused on low TRL, high risk (or critical) components, allowing for efficient 
allocation of resources. 

3 TRANSITIONING CRITICAL TECHNOLOGIES 


This section describes how key technologies were chosen and integrated into CASTOR and what 
risks stem from them. 

3.1 DIVERGING CUSPED-FIELD THRUSTER 


Criteria 

The propulsion system onboard CASTOR will use electric propulsion to propel the small 
satellite. Using the Diverging Cusped Field Thruster (DCFT) as its primary propulsion system, 
CASTOR must operate for throughout the mission lifetime of 1 500 hours. Hence, the propulsion 
system must likewise be operable for the same amount of time so that on-orbit performance, 
efficiency, and degradation of the DCFT can be measured and compared to thrusters of similar 
technologies. 
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The DCFT is believed to have better overall performance and lifetime than other electric 
thrusters for the following reasons: 

• No central body 

• Improved anode design 

• Better plasma confinement 

• Use of permanent magnets as opposed to electromagnets 

For these reasons, it was chosen as the propulsion system for CASTOR. The purpose of the 
mission will be to validate the performance. 

Activities 

The thruster being used on CASTOR is a Diverging Cusped Field Thruster that was designed by 
Dan Courtney, a graduate student at MIT. A prototype of this thruster was built by MIT students 
in the spring of 2008 and it was modified and tested the in the summer of 2008. The thruster uses 
Xenon propellant and will produce an Isp that scales with the amount of power sent to the 
thruster. For this mission, the thruster will be operating with an Isp around 1200 s. 

The thrust that is produced by the thruster also scales positively with the amount of power given 
to the thruster. Testing at 162.6 W (the previous operating power of the thruster), the thruster 
produces .0071 N of thrust. However, our new operating power for the DCFT is 100 W, but 
thrust output tests at this power have yet to be completed. The thruster will be fired continuously 
while CASTOR is in sunlight and will be turned off during eclipse periods. The engine’s heater 
that runs at 36 W will remain running during eclipse periods in order to prevent the need for 
reconditioning when the satellite enters sunlight periods again. However, we are currently 
looking into ways to conserve power by not operating the heater during eclipse but instead 
running the keeper in the cathode, which uses only 1 5 W of power. 

The cathode is part of the electric propulsion engine and the DCFT. The cathode emits charged 
particles that interact with the Xenon particles leaving the thruster to neutralize them and create a 
plasma beam leaving the engine. A cathode identical to the one used for thruster tests will be 
purchased from Busek, Inc. The cathode must be run with 1 5 W of power whenever the thruster 
is firing. The DCFT is shown in Figure 12. 
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FIGURE 12: SOLIDWORKS DESIGN OF THRUSTER 


Risks 

The primary risk inherent in the DCFT is that it is still in the development and characterization 
stage. Not only does this lead to technical risks, but also programmatic risks in that there are 
many unknowns and fabrication/testing could lead to schedule slips. The primary technical risks 
include poisoning of the cathode, failure of the heater/keeper, anode material degradation, and 
lack of power to the anode. Each of these risks is being mitigated as much as possible at this 
point, but this is largely in flux due to the current testing of the DCFT. 


3.2 XENON FEED SYSTEM 


Criteria 


The criteria for choosing the Xenon Feed System (XFS) were primarily based around: 


• Functionality of the system 

• Mass of the components 

• Cost of the components 

• Risk of the system 


It should be noted that the alternative to the XFS is a custom feed system that was developed by 
the CASTOR team. This system had a mass of nearly double that of the XFS. Furthermore, the 
system is provided to CASTOR by NASA at no cost and the XFS will be extensively tested prior 
to being delivered to the CASTOR program. 
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Activities 


The feed system is the controller for the mass flow rate of Xenon gas into the cathode and DCFT 
(anode) of the propulsion system, as seen in Figure 13. It regulates the flow ensuring the 
optimum amount of xenon continues through the system so that the maximum amount of xenon 
ions are produced when the gas flows through the DCFT creating the most efficient use of the 
propellant. 



FIGURE 13: NASA XENON FEED SYSTEM 

The NASA system, seen in Figure 13, was developed by Gray Research and NASA and is 
currently still in a testing phase at NASA with a last reported Technology Readiness Level 
(TRL) of 5. It weighs 0.73 kg in total, taking in gas at an inlet pressure of 3000 psi and releasing 
it at 15 psi. The system can regulate the flow between 0 and 10 seem. Due to thermal expansion 
and contraction the Pressure Control Module (PCM) that Castor will be using as its primary flow 
control device has a constrained operation temperature of 0-50 degrees Celsius under normal 
operation from 30-3000 psi inflow to the module. As temperature increases above the operating 
range, the feed system begins to a have small steady state error in its control loop response with 
little response time variation and good stability nonetheless. 

Risks 

Given that the XFS is being provided to the CASTOR program by NASA, it is projected to have 
a much lower level of technical risk due to the construction and testing it will undergo by 
professionals. However, delivery by NASA also implies significant programmatic and schedule 
risk given that NASA may fail to meet CASTOR program deadlines. Technical risks include 
xenon feed rate not being accurate and inability to adjust mass flow rate into the thruster. 
Mitigations for these risks are being explored and developed, but much of this will continue as 
the XFS is integrated into the propulsion system. 
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3.3 SOLAR PANEL DEPLOYMENT 


Criteria 

Given the UNP’s requirement of surviving 20G loading, the mechanisms connecting each solar 
panel to the primary structure of the satellite must be able to withstand a certain load to meet that 
requirement and survive launch. Specifically, if each Solar Panel is estimated to have 
approximately 1kg of mass (an upper estimate, based on mock-up models), then all of the 
brackets connecting to each Solar Panel must support 200N of force in total without failing. 
Assuming that each solar panel will be supported by 6 or more connectors and approximately 
equal loading distribution, each connector must therefore be able to support at least 34N. 

In addition, because deployable solar panels are necessary to meet minimum power 
requirements, a mechanism for reliably deploying 2 of the solar panels must be included. 

Furthermore, given that the solar array deployment is critical for complete achievement of the 
CASTOR mission, it is necessary that the mechanism be able to deploy with high reliability. 
More importantly, it must be able to not deploy in the Launch Vehicle environment and therefore 
potentially endanger other payloads. 


Activities 

In designing a new Solar Panel Release Mechanism (SPRM), the following factors were 
considered: (1) striving for simplicity to maximize the probability of successful Solar Panel 
deployment; (2) lowering mass and power requirements to minimize impact on the mass and 
power budgets; (3) incorporating a reasonable margin for error, (4) ease of manufacturing. 

Each SPRM will be driven by a linear actuator. Once activated, the actuator will retract its pin, 
after which the two solar panel pins attached to each of the adjacent Solar Panels will be 
released. Then, with the help of an external spring mechanism, the Solar Panels will be able to 
deploy. This SPRM will constrain the deploying Solar Panels in the X, Y, and Z directions and 
will be much more robust than the previous release mechanism. 

The SPRM will consist of the following components: 2 solar panel pins, 1 linear actuator, and 
one bracket to hold everything together and attach the mechanism to the primary structure. The 
bracket will be made of several 1/4” and 1/8” thick aluminum extrusions for ease of fabrication. 
There will be two SPRMs in total, all located on the farthest point of Truss 1 in the -Z direction. 
The SPRM, if made from 6061 Aluminum, has a mass of 0.08kg including the full linear 
actuator assembly. 
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FIGURE 14: SOLAR PANEL RELEASE MECHANISM 

THE SECOND ITERATION OF THE SOLAR PANEL RELEASE MECHANISM, SIDE VIEW (LEFT), 
ISOMETRIC VIEW (CENTER), BOTTOM VIEW (RIGHT). THE CURRENT DESIGN INCORPORATES AN 
INDUSTRY LINEAR ACTUATOR AND IS MORE MASS EFFICIENT. 


Risks 

The primary risk of the deployment system is that the deployment mechanism fails during launch 
and therefore puts other payloads at risk. Since this is an unacceptable occurrence, it is 
necessary to ensure the deployment system is designed with high safety factor, contains as much 
redundancy as possible, and is extensively tested. The second main risk is that the deployment 
system will fail to deploy when on-orbit. This is also mitigated primarily through testing since 
failure to deploy would result in a serious penalty to mission objectives. 
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4 INTEGRATION OF SYSTEMS ENGINEERING EFFORT 


4.1 REVIEWS AND FREEZES 


During production there comes various times where the design must be reviewed and checked. 
Attendees to these reviews include professors, people in industry, and University Nanosatellite 
reviewers. For reviews it is important that every team member is operating with the most up to 
date information. Thus, design freezes are implemented for these reviews typically two weeks in 
advance. 

At the reviews, each part of the design of the CASTOR satellite is reviewed and comments are 
noted and addressed. After each review, a Systems compiled list of action items collected from 
the review is sent out to each team, informing them of what changes must be implemented into 
our design with a priority set on each one. 

Additionally, design freezes serve as a method for checking in with each team. It is easy for 
teams to lose track of what changes have been made to the design if they are not directly related 
to their section of the satellite. Because of this there can be mistakes made when moving 
forward as teams may design for out of date components. When the design is frozen, there are 
updated data sheets, design documents, equipment lists and other command media Systems 
manages that are available to each sub-team as a point of reference as the project moves forward. 

4,2 CONCURRENT ENGINEERING OF HARDWARE/SOFTWARE 

Both hardware and software for CASTOR are constantly evolving. As such, it is important to 
make sure that any changes in either aspect of design is tracked and noted. Most of the 
interfaces between hardware and software fall under the responsibility of the avionics sub-team 
managed by the systems team. The hardware provides the physical connections and logic 
circuits necessary for connecting to sensors and actuating devices. The software provides the 
logic for ensuring that the sensor data is acted upon properly. 

When a sub-team determines that they require a hardware component for their operations and 
need to control it, they inform the Systems who will make assign responsibility to someone on 
avionics. However, if any changes are made to either the physical component or the type of 
software implementation, it is crucial that both the avionics team and team responsible for the 
component are kept up to date. This is done through the team leads meetings as well as direct 
communication with Systems and the sub-teams throughout the week. 
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4.3 SUBSYSTEM TESTS, INTEGRATED TESTS, PLANNED INTEGRATION 

PERIODS 


Since the design of the CASTOR satellite is relatively mature, each team is now taking on the 
task of integration with other teams. During this phase of design it is particularly important for 
team communication to be facilitated through the Systems Team. When sub-teams need to 
schedule joint lab time they can submit their requests at the team leads meetings held by Systems 
each week. 

The integrated testing is managed by the Systems team to allow for streamlined operation during 
the test. Integrated tests include thermal vacuum and shake table tests were components from 
multiple teams are integrated. These tests take place off MIT campus at MIT Lincoln 
Laboratory. In order to reserve time at these labs the tests must be scheduled ahead of time and 
must have sufficient personnel to run the experiments. 

4.4 CRITICAL PATH MANAGEMENT 


One approach that CASTOR has used to improve 
the robustness of schedule management is to 
introduce Critical Path Management (CPM). A 
simple Gantt chart shows the expected run time of 
each task or project and displays them against a 
calendar. This is useful for visualizing the time 
breakdown of individual tasks but this does not give 
very much insight to a program manager as to what 
tasks may be high risk for creating a bottleneck in 
the process if they aren’t completed in time. 

Critical path management displays each task as a 
state in a state diagram and lists the expected early start, early finish, late start and late finish 
times. This state diagram incorporates dependencies that certain tasks have with others. For 
example, the Master Equipment List (MEL) cannot be finished and submitted until ADCS 
determines which brand of sun sensor to use. If the systems team is constantly aware of these 
dependencies then they will know the extent of the consequences if, say, the ADCS team falls 
behind. Once this state flow is created the critical path can be determined. The critical path is 
defined as the flow path through the states from project start to finish which, in total, takes the 
longest time to complete. 

This gives the program manager a visual reference to decide if they want to shuffle tasks around 
to have more risk adverse schedule. More complicated forms of CPM can morph into PERT 



FIGURE 15: CRITICAL PATH 
MANAGEMENT 
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analysis and Design Space Matrices (DSM) which incorporate possible design iterations into the 
schedule. These have not yet been incorporated into the program. 

5 IMPLEMENTATION TASKS 


S.l TESTING 

The CASTOR satellite must undergo extensive testing to create mission assurance. Mission 
assurance is defined as the general system engineering, quality, and management principles 
towards the goal of achieving mission success, and, toward this goal, provides confidence in its 
achievement. Mission success is defined as the achievement of a system to singularly or in 
combination meet not only specified performance requirements, but also expectations of the 
users and operators in terms of safety, operability, suitability, and supportability. Mission 
assurance focuses on the detailed engineering of the acquired system, and, toward this objective, 
uses independent technical assessments as a cornerstone throughout the entire concept and 
requirement definition, design, development, production, test, deployment, and operation phases. 

There are three key reasons why a test should be performed. These reasons and the rationale 
behind them are listed below. 

1 Functionality verification 

1 . 1 Evaluate that the as-built system (including interfaces) satisfies the requirements and 
specification baseline. 

1 .2 Identify issues with the proposed test, integration, and verification plans and 
procedures 

2 Reduce Risk 

2.1 Evaluate appropriateness and risk of verification by any method other than testing. 

2.2 Evaluate risks associated with deviations from environmental testing standards (e.g., 
MIL-STD 1 540) and other applicable standards or best practices. 

2.3 Evaluate the fidelity to the “test like you fly” (TLYF) and “test what you fly” 
philosophies, especially at the system and higher levels of integration, and identify 
risks associated with deviations from these philosophies. This includes implications 
to accurate modeling and simulation. 

3 Unfamiliar Area 

3.1 Evaluate analysis, simulation, inspection, and test results to determine readiness to 
proceed to subsequent test or program activities. 


All testing will follow begin at the component level, progress through the subsystem level, and 
finish at the assembly level. There may be additional tests between the three major levels, but as 
a minimum, all aspects of the design will be tested in this order for the reasons listed above. 
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All test plans can be found in the associated test plans The three system level tests are the 
Balloon SHOT (II), Vibration, and Thermal Vacuum test and are listed with the subsystem 
performing them 


5 1 1 INDEX OF TESTS 

• Avionics 

o EMC/EMI August 2010 

o FlatSat I (Ground station Communications) November 2009 
o FlatSat II (Read Thermal/Power Sensor Data) May 2010 
o FlatSat III (Read/Operate ACS sensors) May 2010 
o FlatSat IV (PPU/Linear Actuators/Inhibits) May 2010 
o FlatSat V (Operate XFS) May 2010 
o FlatSat VI (Radiation effects) May 2010 
o Balloon SHOT (II) June 1 1 - 1 3 th 20 1 0 

• Communications 

o Antenna April 2010 

• ACS 

o GPS November 2009 
o Magnetometers March 2010 
o Reaction Wheels March 2010 
o Torque Coils June 2010 
o Sun Sensors October 2010 

• Power 

o Integrated PPU May 2010 
o MPPT July 2010 
o On-board Charger May 2010 
o PDU April 2010 
o FlatSat August 2009 
o Solar Power April 2010 

• Structures 

o Vibration March 2009, February 2010, October 2010 
o Thermal- Vacuum March 2010, October 2010 

• Science 

o Camera Avionics May 2010 
o Camera Functional September 2010 
o Camera Thermal- Vacuum April 010 
o Camera Vibration April 2010 

• Propulsion 

o DCFT Efficiency April 2010 
o Feed System June 2010 
o Integrated PPU May 2010 
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The key tests are as described in following sections 


5 1 2 SOLAR ARRAY TESTING 

Due to the high power requirements of CASTOR and the fact that students are assembling the 
solar arrays, it is critical to perform extensive testing of the solar arrays The current 
configuration next needs to be tested to see if it gives enough power to run each team's 
equipment If the voltage, current, and resulting power provided encompasses the power needs, 
then the solar panel setup is properly designed 

This initial test will verify that the solar cells provide the correct voltage, currents, and power 
that are equivalent with the documentation The light source used should illuminate the entire 
solar panel Since the CASTOR design involves two solar panels at 45° to the sun, it is also 
necessary to test the effects of having the light falling on the solar cells at different angles other 
than straight overhead The light source used should illuminate the entire solar panel Finally, it 
is necessary to ensure that the amount of power that each subsystem expects is correctly 
supplied The light source used should illuminate the entire solar panel As this test involves the 
complete setup, a light source similar to a spotlight is recommended 

5 1 3 FLATSAT TESTING 

Furthermore, it is necessary to perform a Flatsat of the satellite, which ensures that all 
components in the satellite are able to communicate with each other This involves 
demonstration of the ground station's ability to transmit commands and the satellite's ability to 
receive commands and execute as expected CASTOR has chosen to split the Flatsat testing up 
into a series of tests that can be performed in sequence as different parts of the system are ready 
for testing This helps to ensure that the program remains on schedule and minimizes critical 
paths These tests range from Flatsat I, which demonstrates basic ground station capabilities to 
Flatsat VI, which demonstrates the avionics system’s capability to withstand the radiation 
environment of space 


5 2 COTS VERIFICATION 


Due to inconsistencies in COTS products matching precisely with their documentation, testing of 
COTS components is required to ensure reliability as well as proper integration with the overall 
system One example of verification of COTS components is testing of the communication 
antennas Since the 8 and 11 dBi antennas responsible for communications with the ground 
station are COTS, anechoic chamber testing was performed to ensure that first, the antenna met 
the specifications, and second, that modifications to the antenna would not be detrimental to the 
system Testing the antenna by itself, and then as a system with the satellite would lead to 
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increased TRL. Testing was performed at MIT Lincoln Laboratory (a professional facility 
located about half an hour from MIT). A comparison between actual performance and the 
specifications is shown below. 



ISO- 


FIGURE 16: ANTENNA TEST RESULTS 



FIGURE 17: ANTENNA SPECIFICATIONS SHEET 

From the graph of the radiation pattern, it is apparent that the quality of the antenna does not 
quite meet the specifications, but it was concluded to be sufficiently high to meet subsystem 
communication requirements. 


6 ADDITIONAL SYSTEMS ENGINEERING ACTIVITIES 


Because of limitations in the CASTOR budget and the significant expense of flight model 
components, it is important to confine purchases and ensure that savings are found wherever 
possible. Team members manufacture most components on our satellite, saving the team a 
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significant amount of money. We are also able to generate several donations from companies 
who wish to sponsor our satellite. However, being participants in a competition, we must 
account for the possibility that our design might not be selected for flight. Because of this there 
are some components that may be imprudent to purchase at this phase in our design. 
Massachusetts Space Grant also helps support undergraduate students for their research 
contributions to the project, as well as unique testing projects run related to CASTOR organized 
by students. 

The current design calls for the use of three reaction wheels and four sun sensors. Due to the 
extremely high cost of these components, we have decided to rent engineering models from the 
manufacturers. These components have the same interfaces, mass, and functionality as the flight 
model version but are not as precise or expensive. Because we have decided to do this we are 
operating within our budget and able to demonstrate the functionality of our satellite. 

Ordered components are largely delivered in the span of a couple of days. There are very few 
long-lead items that we need to account for, but those that need to be purchased have been done 
so early in the design, and those components that are not in our possession are not limiting 
factors as we can continue design with a mock up until the component arrives. 

7 CONCLUSION 


The CASTOR mission is a complex project requiring the deep involvement of systems 
engineering concepts in its conception and development. Through careful systems planning, 
analysis and implementation, CASTOR continues to move forward as a project with the aim of 
improving efficiency of electric propulsion systems. High-performance propulsion systems have 
application to missions beyond GEO, allowing more efficient access to LaGrange Points, the 
Moon and beyond. With its strong mission relevance to the future of space exploration, 
CASTOR shall continue to progress towards the project requirements and objectives. After 
accomplishing post-CDR feedback, the CASTOR team will begin fabricating the satellite 
components for its prototype qualification review (PQR) in August of 2010. Finally, the 
complete satellite will be built for flight competition review (FCR) in January of 2011, and 
hopefully a launch soon after. 

Finally, CASTOR’s importance lies not only in its technical demonstration, but also in its 
application of making small spacecraft design a reality for not just NASA and the military, or 
even commercial industry, but also university students. Providing students with the opportunity 
to learn how to design, implement and operate space systems while thinking with a systems- 
perspective greatly contributes to their education as engineers, and shall serve them in their 
future careers. 
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9 APPENDICES 
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50 00 

20% 

60.00 ] 0.10 

20 00% 

0.12 

Propulsion 

NASA Peed 



0.00 

0% 

0 00 ] 0 75 

15 00% 

086 

Propulsion 

Pressure Relief Valve 



14430 

10% 

158.95 02; 

1000% 

0.24 

Propulsion 

Tank 

luxfer 14SJ 


350.00 

5% 

36730 295 

5.00% 

3.10 

Propulsion 

Tank Adapter 



200.00 

5% 

210.001 0.20 

5.00% 

0.21 

Propulsion 

Xenon fuel 

AirGas 


25,500 0C 

10% 

28.350 00 5 1( 

» 

5.36 

Propulsion 

Manual Valve 

McMaster Carr; part *7833X999 


50 00 

10% 

55.00 1 OIS 



: 

> 

Propulsion 

Solenoid Valve 



100.00 

15% 

115.00 0.03 

15% 



AM rows above thn row M not delete this row 







1 

Total 




39.64*30 


*3.928 951 1223 


1309 

»~r- 




*2.000 00 

10% 

*6.12* 62 [ 1230 

5% 

13.13 


Nickel Cadmium Batteries 

Rechargeable NiCad 4500 mAh batteries (with lab). HCD 0*5008 

20 

155 80 

0% 

15SJ0I 232 

0% 

2.: 

2 

. 

Power 

Seder Cafe 

Loral Space Systems (Donated) 

416 

0.00 

15% 

0.00 0 29 

10% 

03 

Power 

Solar Cell Coveigiass 

Local Space Systems (Donated) 

416 

ooc 

0% 

0 00 0.25 

10% 

0 27 

Power 

Anode Converter (PPU) 

American Power Design OC/DC converter. HI SO 200 


290 00 

0% 


0% 

060 

Power 

Cathode keeper Converter (PPU) 

Vicor OC/DC converter. V24C36M50BL3 


90 00 

0% 

9000 ] 000 

OH 


Power 

Cathode Heater Converter (PPU) 

Vkxv OC/DC converter. V24C1SM100L3 

1 

90.00 

0% 

30-00 1 0 07 


0.07 

Power 

Cathode Heater OAC (PPU) 

Microchip. MC p 4B21 

1 

2.30 

0% 

2.30 o.o: 



Power 

PPU PCB 

Custom board 


66 00 

0% 

66.00 1 0 08 

cm 

006 

- ■ - 

3.3V Converter (POU) 

TDK Lambda OC/DC Converter, COS 2403V E 


4500 

0% 

*5 00] 002 

0% 

002 

Pow» 

POU PCB 

Custom board 

— 

66 00 

0% 

66.00 1 004 


004 

Posner 

MPPT 

Have m Lab 

1 

300.00 

0% 

300.00 0.60 

OH 


,W 

IM PCB Board 

Custom Board; 24'a30* 

8 

1.088 00 


1.088.00 2.38 

10H 

2.61 

Power 



2 

ioooo 

0% 

10080 1 019 

40% 

0J 

- 

Posner 

Af 163 2*0 045 

3M Scotch Weld 

] 

463.50 

0% 

46330 025 

5H 

0 


500'f Ouraico 128 eenmie besed epoxy 

Cotronics Corp 

1 

65 00 

0% 

10% 

10% 

65 00 0.44 

10% 

048 

Poster 

Non- acid soldering (lua liquid 

McMaster Carr; part P776SA11 



10 00 

1 11.001 0.00 

10% 

OOO 


MIT CASTOR NASA ESMD Paper 


Page 52 


9 APPENDICES 


9.1 MEL 


Master Equipment List Updated on 04/20/2010 

1 — 


Subayttam 


— 
Description (Vendor, part 1, etc.) 

• Items 

TWafCMM 

CM 

Margin 

Margined CM 

Tbtal Meat 

HAH 

Maas 

Margin | 

Margined 


Systems 

Testing 


i 

S.ooooo; 


S.OOOOO 




V^lwm 

Travel lo POP 

flight hotel and foM 

i 

3.516 00 

25% 





*n<e«m 

Travel to TCP 

fight hotel and food 

1 

3.516 00 

25% 





| Systems 

Shipp** Satellite 


2 

1-000 .00 1 

25% 

1.250 00 


| AM riMr* above this row do not delete #H» row 









[Total 




s.ooooo 


5.000 00 

3.00 1 

1 

300 

Alotafon 




12.000 00 

40% 

16B00 00 

3*1 

5%| 

OOO 

|OMi 










AM rows itwt t An row M not delete this row 









Total 




0.00 1 


300 

3.00 1 

r 

ooo 

AtoutMn 




3.00 


330 

55 

3%| 

ooo 

Operators 

labor 

cost of labor at ground station (free student labor) 

0 

0.00 

0% 

000 

0 00 


ooo 

Operations 

MET? 

ground station 

1 

15.000 00 

25% 

18,750 00 


0% 

ooo 

Operations 

MIT Control Center 


1 

6.000 00 

25% 


ooo 

0% 

ooo 

| AM rows above thn row do not delete thn row 









Total 




21.000 00 


26.250 00 

3.00 


ooo 

|Alotafon 




25.000.00 

15% 

28.750 00 

3.00 

3%| 

0.00 

ns — 

B5 

Peectton wheel Assembly 

Analog Devices, ioM state gyros, tn aan AD'S 16355/AMtf 


620 00 
90.000 00 

10% 

10% 

682.00 
99.000 00 

0.02 

068 

10% 

10% 

002 

074 

ACS 

AO 

Sun Sensor 

SS-411 from Sinclair interplanetary 


40.000.00 

750.00' 

15% 

90080 

0 i* 
0.75 

15% 

20% 

016 

090 

f AO 

MicoMag Ml Magnetometer 



480.00 

5% 

504 00 

0.04 

o%! 

004 

[ACS 

Magnet 



1.000 00 

15% 

1.150 00 

025 

25% 1 

031 

[ AM row* above thn row do not delete this row 









Total 




132.850.00 


1*1.236 30 

1 88 


218 

Al ocefon 




133.000 30 

15% 

152.950 30 

1.90 

13%) 

219 


GPS Receiver 

space GPS receiver; SSTl GPS SGR 05 from Surrey 

1 

23.010.00 

10% 

25.31100 

002 

10%] 

0 02 

GNC 

GPS Antenna 


* 

000 

1(7% 

0 00 

0.01 

10% 

0.01 

| AM rows above thn row do 

not dciete this row 









Total 




23.013 03 


25.31100 

3 03 


094 

|Al'0cat*on 




24.000 00 

10% 

26,400 00 

3.04 

io%| 

0.04 


Igb KANO flash module 

Micron MT29F 1G01ZAC. SPI 


75 00 

15% 

8625 

0.02 

25% | 

0.03 

0.10 

Avwjn.cs 

custom PCB (not including dsPiC or CAN chips) 

components will mount to this PCB. solder included In MCI 

1 

156.00 1 20% 

187.20 

008 

20% 

jAvtonlcj 

dsPtC3 SPJ2 S6GP802 

Expands CPU I/O diversity adding SPi and A20 

3 

15.30] 

10% 

1683 

006 

10% | 

0.07 


CAN Level Converter Chips 

estimates from dtgikey, Converts voltages to CAN level from chip 
outputs 

3 

4.50 

15% 

I - 

5.1 

J oo_ 

ooo 

15% 

20% 

005 

Avionics 

Resistor s/Capacitors 

Surface mount components for PCB 

IOC 

s.oc 


S3 

ooo 

Avionics 

Software incense 


1 

1.00000 

10% 

1-ioooc 

0.00 



AM rows above thn row M not delete this row 



0.00 






Tbtal 




1.255 B0 


l.*009t 

t 02 


0.24 

Afcvahon 




1.900 00 

9% 

1.390*4 [ 3 30 

5% 

0.32 

Communications 

8dB« patch antenna 

Worn HG2409P NF 


22.00 

5% 

23. 1C 

| 0.06 

15% 

007 

Tonmiili iTuni 

modems 

modem, put in boa and mount with bolts; Microhard MHX2420 OEM 
2.4 GHr. has built m voltage and temp sensors 

2 

LGOOOO 

5% 

1.6SO 0C 

0.09 

5% 

0.10 

Communications 

cabling and connectors 

N Male VC* Male. Citrus Cables NPMC 10005 

2 

50 00 

20% 

60 OC 

0.10 

40% 

0.15 

Communications 

11 d« patch antenna 

L-Com ttllDSNM 

1 

30 00 

5% 

S1.5C 

0.10 

15% 

0.12 

AM roars above thn row. M not delete this rm 









Total 
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1.794 6 
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3.43 

*•»>*«" 
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3% 
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0.12 
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Propulsion 
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10% 

158.95 02; 
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0.24 

Propulsion 

Tank 

luxfer 14SJ 


350.00 

5% 

36730 295 

5.00% 

3.10 

Propulsion 

Tank Adapter 



200.00 

5% 

210.001 0.20 

5.00% 

0.21 

Propulsion 

Xenon fuel 

AirGas 


25,500 0C 

10% 

28.350 00 5 1( 

» 

5.36 

Propulsion 

Manual Valve 

McMaster Carr; part *7833X999 


50 00 

10% 

55.00 1 OIS 



: 

> 

Propulsion 

Solenoid Valve 



100.00 

15% 

115.00 0.03 

15% 



AM rows above thn row M not delete this row 







1 

Total 




39.64*30 


*3.928 951 1223 


1309 

»~r- 




*2.000 00 

10% 

*6.12* 62 [ 1230 

5% 

13.13 


Nickel Cadmium Batteries 

Rechargeable NiCad 4500 mAh batteries (with lab). HCD 0*5008 

20 

155 80 

0% 

15SJ0I 232 

0% 

2.: 

2 

. 

Power 

Seder Cafe 

Loral Space Systems (Donated) 

416 

0.00 

15% 

0.00 0 29 

10% 

03 

Power 

Solar Cell Coveigiass 

Local Space Systems (Donated) 

416 

ooc 

0% 

0 00 0.25 

10% 

0 27 

Power 

Anode Converter (PPU) 

American Power Design OC/DC converter. HI SO 200 


290 00 

0% 


0% 

060 

Power 

Cathode keeper Converter (PPU) 

Vicor OC/DC converter. V24C36M50BL3 


90 00 

0% 

9000 ] 000 

OH 


Power 

Cathode Heater Converter (PPU) 

Vkxv OC/DC converter. V24C1SM100L3 

1 

90.00 

0% 

30-00 1 0 07 


0.07 

Power 

Cathode Heater OAC (PPU) 

Microchip. MC p 4B21 

1 

2.30 

0% 

2.30 o.o: 



Power 

PPU PCB 

Custom board 


66 00 

0% 

66.00 1 0 08 

cm 

006 

- ■ - 

3.3V Converter (POU) 

TDK Lambda OC/DC Converter, COS 2403V E 


4500 

0% 

*5 00] 002 

0% 

002 

Pow» 

POU PCB 

Custom board 

— 

66 00 

0% 

66.00 1 004 


004 

Posner 

MPPT 

Have m Lab 

1 

300.00 

0% 

300.00 0.60 

OH 


,W 

IM PCB Board 

Custom Board; 24'a30* 

8 

1.088 00 


1.088.00 2.38 

10H 

2.61 

Power 



2 

ioooo 

0% 

10080 1 019 

40% 

0J 

- 

Posner 

Af 163 2*0 045 

3M Scotch Weld 

] 

463.50 

0% 

46330 025 

5H 

0 


500'f Ouraico 128 eenmie besed epoxy 

Cotronics Corp 

1 

65 00 

0% 

10% 

10% 

65 00 0.44 

10% 

048 

Poster 

Non- acid soldering (lua liquid 

McMaster Carr; part P776SA11 



10 00 

1 11.001 0.00 

10% 

OOO 
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9.2 RVM 



Mission Statement 




Legend 


MS.l 

The mission of the MIT Nanosatellite (CASTOR) is to validate the performance and 
application of Diverging Cusped Field Thruster (DCFT) technology and the Xenon Feed 
System (XFS). This will be achieved by taking on-orbit state data to compare the 
degradation experienced by the DCFT to that of similar technologies. 


Mission 

Statement 

Mission 

Requirement 


Constraints 




Constraint 

System 

Requirement 

MC.l 

Satellite program and hardware must comply with UNP Requirements 


Subsystem 

Requirement 

Requirement 
NOT met 






Requirement 

Met 

Requirement Met 
but not verified 


Mission Requirements 

Source 

Justification 

Status 



M.l 

Measure the on-orbit performance, efficiency, 
and degradation of the DCFT during orbital 
maneuvers 

MS.l 

Validates the performance and 
application of the DCFT 




M.2 

Operate the DCFT on orbit for 1500 hours 

MS.l 

Proves the DCFT lifetime is 
comparable to similar 
technologies 




M.3 

Give the Xenon Feed System flight heritage 
by incorporating it into the propulsion 
plumbing. 

MS.l 

Validates the performance and 
application of the Xenon Feed 
System 


Verification 

Source 

Document 

Test/ Analysis 
Number 







System Requirements: MIT Satellite 
(CASTOR) 






Sl.l 

CASTOR shall have a DCFT as the primary 
propulsion system, which shall operate 
throughout the mission lifetime 

M.l, 

M.2 

A DCFT must be flown to 
measure and compare its on- 
orbit performance characteristics 
to similar thrusters 




SI. 2 

The CASTOR bus must be able to support 
on-orbit mission operations for the mission 
lifetime of at least 6 months 

M.2 

Proves the DCFT can function 
as a propulsion system for small 
satellite operations. A six month 
lifetime allows for 1 500 hours of 
engine operations 




SI .3 

CASTOR shall provide sufficient state data to 
measure the change of performance, 
efficiency, and degradation over the DCFT's 
operational lifetime 

M.l 

Allows the satellite to function 
for as long as needed to measure 
DCFT degradation 




SI. 4 

CASTOR shall utilize the XFS to perform 
closed-loop control of flow to thruster. 

M.3 

XFS is incorporated into the 
system 












CASTOR Propulsion 






SI. 1.1 

The propulsion system will be the DCFT 

Sl.l 

As per the Mission requirement 


CASTOR 

Design 

Document 

Design 

Requirement 

SI. 1.1. 
1 

DCFT must operate at a minimum of 40 to a 
nominal 100 Watts of power supplied to the 
PPU 

SI. 1.1 

The lowest power DCFT will 
fire is 40 Watts [minimum 
success mission]. At 165 Watts, 
DCFT is comparable to other 
thrusters of similar degradation 


CASTOR 

Design 

Document 

Integrated PPU 
test 

SI. 1.1. 
2 

DCFT components must be operable for full 
mission lifetime 

SI. 1.1 

The ceramic cone and other 
DCFT components must survive 
1 500 hours of operating 


CASTOR 

Design 

Document 

Simulation 

SI. 1.1. 
3 

DCFT will undergo cathode conditioning 
prior to operating 

SI. 1.1 

To clean the engine of debris 
and contamination 


CASTOR 

Design 

Con -ops 
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Document 


SI. 1.1. 
4 

DCFT must remain in a heating or thrusting 
mode after cathode conditioning 

SI. 1.1 

When not operating. DCFT must 
be in heating mode. If power is 
not available for heating, the 
DCFT will be turned off entirely 


CASTOR 

Design 

Document 

Con-ops 

SI. 1.2 

The propulsion system will use the XFS as 
part of its propulsion system. 

SI. 4 

As per the Mission requirement 


CASTOR 

Design 

Document 

Design 

Requirement 

SI. 1.2. 
1 

The XFS which must be able to regulate and 
vary mass flow to DCFT 

SI. 1.2 

Mass flow to DCFT allows 
control of electron flow and 
ionization efficiency. Mass flow 
to cathode controls current flow, 
power draw. 


CASTOR 

Design 

Document 

Feed System 
Test 

SI. 1.2. 
2 

The plumbing system on the propulsion 
system must have a minimum of three 
electrically controlled mechanical gas flow 
inhibits 

SI. 1.2 

To ensure that the gas does not 
vent from the plumbing system 


CASTOR 

Design 

Document 

Design 

Requirement 

SI. 1.2. 
3 

The plumbing system will maintain the 
pressure below 4000 (TBR) psi. 

SI. 1.2 

For DCFT to function at its 
highest efficiency, it must 
maintain a low pressure 


BHC-1500 

Operation 

Manual 

DCFT efficiency 
Test 

SI. 1.2. 
4 

The fuel in the propulsion system must have a 
purity of 99.999% 

SI. 1.2 

For DCFT to function at its 
highest efficiency, it must be fed 
pure and uncontaminated Xenon 


BHC-1500 

Operation 

Manual 

Xe spec sheet 

SI. 1.3 

The propulsion system must output current, 
voltage, and mass flow data to avionics 

S1.3 

Requirements for determination 
of performance and efficiency of 
DCFT 


CASTOR 

Design 

Document 

FlatSat V 









CASTOR Imaging 






SI .2.1 

The imaging system must be able to take still 
pictures of the DCFT plume to determine if 
ionization is occurring 

SI. 3 

Evidence of ionization can be 
seen in the exhaust plume within 
a few inches of the DCFT nozzle 


CASTOR 

Design 

Document 

camera 

functionality 

SI .2.1 . 
1 

The imaging system shall be able to take 
color pictures 

SI .2.1 

An ionized exhaust plume is 
blue/purple, while a non ionized 
plume is red 


CASTOR 

Design 

Document 

propulsion 
imaging test 

SI. 2.1. 
2 

The imaging system shall have a spectral 
resolution of 200 nm 

SI .2.1 

The camera must be able to 
distinguish between red and blue 


CASTOR 

Design 

Document 

propulsion 
imaging test 

SI .2.1. 
3 

The imaging system shall use a minimum 
resolution of 320x240 pixels to ensure that 
there is enough detail for spectral analysis. 

SI. 2.1 

The camera must be able to pick 
out the plume from other objects 
in the frame of view 


CASTOR 

Design 

Document 

Initial camera 
testing 

SI .2.1 . 
4 

The imaging system camera must be mounted 
to the structure and pointed towards the 
DCFT nozzle to analyze plume shape and 
color 

SI .2.1 

Camera must be secured enough 
and directed correctly to analyze 
plume 


CASTOR 

Design 

Document 

Engineering 

Model 

SI .2.1. 
5 

The thruster monitoring camera shall have a 
field of view between 50° and 70° 
(diagonally). 

SI. 2.1 

A field of view in this range will 
allow camera images to capture 
the cathode, the anode, and a 
significant portion of the plume. 


CASTOR 

Design 

Document 

Camera Spec 
Sheet 

SI .2.1. 
7 

The thruster monitoring camera shall be 
sufficiently protected and kept within spec 

SI. 2.1 

The camera must be working in 
order to collect data 


CASTOR 

Design 

Document 

Balloon SHOT 

(II) 

SI .2.1 . 
7.1 

The thruster monitoring camera must operate 
between 3.0 V and 3.6 V, and at 60 mA 

SI .2.1 . 
7 

C328R-7640 camera 
specifications 


CASTOR 

Design 

Document 

camera avionics 
testing 
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Sl.2.1. 

7.2 

The thruster monitoring camera must operate 
between -20°C and 60°C 

Sl.2.1. 

7 

C328R-7640 camera 
specifications 


CASTOR 

Design 

Document 

Thermal Vacuum 
Test 

Sl.2.1. 

7.3 

The thruster monitoring camera shall be 
sufficiently shielded to survive and operate 
for 6 months 

Sl.2.1. 

7 

The camera must provide 
continuous monitoring of the 
thruster and thruster plume to 
obtain a complete performance 
data set. The high radiation 
environment around the thruster 
will tend to degrade the camera 
and its electronics, so it must be 
protected. 


CASTOR 

Design 

Document 

Aluminum 
Degradation Test 

SI. 2.2 

The imaging system must be able to transmit 
and store image data in avionics system 
memory 

S1.2 

Imaging data must be stored so 
it can be transmitted to ground 
for study 


CASTOR 

Design 

Document 

FlatSat M Camera 
Avionics 

SI. 2.2. 
1 

Imaging must be able to interface with the 
avionics and communications subsystems to 
transmit stored image data to ground station 

SI. 2.2 

Imaging data must be analyzed 
on ground 


CASTOR 

Design 

Document 

FlatSat 1/ Camera 
Avionics 

SI. 2.3 

Imaging system must be able to capture 
images at least once per orbit and store 
images for up to two weeks 

SI. 2 

Imaging data must be collected 
regularly to monitor DCFT 
outflow 


CASTOR 

Design 

Document 

FlatSat V Camera 
Avionics 

SI. 2.3. 
1 

Imaging must be able to send image data to 
ground station at least every two weeks 

SI. 2.3 

Image data may only be stored 
for two weeks, images older than 
two weeks may not be stored 
and transferred. 


CASTOR 

Design 

Document 

FlatSat 1/ Camera 
Avionics 









CASTOR Power (EPS) 






S 1 .3.1 

EPS must generate, store, regulate, and 
distribute power to the spacecraft 

S1.1, 
SI. 2 

The spacecraft (to include the 
DCFT) require power to 
complete the mission 


CASTOR 

Design 

Document 

power FlatSat 1 

Sl.3.1. 

1 

EPS must provide 85W to DCFT, specifically 
1 6W to the Cathode keeper and 59W to the 
anode. 

SI. 1.1 

We are not constantly operating 
the anode. The Cathode Keeper 
will always be on. This requires 
that EPS provide 1 6W. 


CASTOR 

Design 

Document 

power FlatSat 1 

Sl.3.1. 

2 

EPS must provide sufficient power to run 
power generation, communications, and 
status of health monitoring, indefinitely. 

Sl.3.1 

The satellite must be able to 
operate indefinitely to account 
for any failures 


CASTOR 

Design 

Document 

power FlatSat 1 

Sl.3.1. 

3 

EPS must provide 1 00 W to the PPU while 
operating and 40 W while heating 

Sl.3.1 

The DCFT requires power to the 
anode and cathode during 
different operational states 


CASTOR 

Design 

Document 

power FlatSat 1 

Sl.3.1. 

4 

EPS must be able to generate 1 13.7W in a 
fully operational state. 

51.3.1, 

51.3.1. 
2 

All critical systems require 
85.91 W and batteries require 
27.79W to charge 


Power Budget 

solar panel test 

Sl.3.1. 

5 

Batteries shall have a capacity of 40Wh to 
support spacecraft operations over mission 
lifetime 

Sl.3.1 

Total battery capacity is a 
consumable, and batteries must 
be able to store enough energy to 
run heater and supporting 
components when in eclipse 


CASTOR 

Design 

Document 

power FlatSat 1 

Sl.3.1. 

6 

EPS shall regulate bus voltage and distribute 
power to operate subsystem components 

Sl.3.1 

Different components require 
different input voltages, so the 
power must be regulated 


CASTOR 

Design 

Document 

power FlatSat 1 

SI. 3 .2 

EPS shall provide state data to determine 
DCFT state, track DCFT power efficiency, 
and to monitor bus health 

S1.3 

EPS data is necessary for 
monitoring system state and 
downlinking information for 
performance analysis 


CASTOR 

Design 

Document 

power/launch 

FlatSat 

SI. 3 .3 

EPS shall be in a safe launch state and shall 
power on the flight processor after separation 

SI. 2 

Mitigate interference with 
launch vehicle 


UNP User's 
Guide 

power/ launch 
FlatSat 


MIT CASTOR NASA ESMD Paper 


Page 57 


SI. 3.3. 
1 

EPS shall be powered off during launch 

SI .3.3 

To provide a safe interface with 
the launch vehicle, the satellite 
will be powered down at launch 


UNP User’s 
Guide 

power/ launch 
FlatSat 

SI. 3 .3. 
2 

EPS shall provide power to the bus after 
detaching from Lightband 

SI .3.3 

Upon separation from the 
Lightband, the satellite systems 
must be powered 


CASTOR 

Design 

Document 

power/ launch 
FlatSat 

SI. 3 .3. 
3 

The battery shall be launched discharged 

SI .3.3 

A fully charged battery at launch 
is a safety concern for the launch 
vehicle and range 


UNP User's 
Guide 

power/ launch 
FlatSat 









CASTOR Structures 






SI .4.1 

The structure must support interfaces with all 
subsystems 

SI. 2 

Must use materials that are 
compatible with thermal 
requirements; must allow 
C&DH to control latches and 
actuators 


CASTOR 

Design 

Document 

Design 

Requirement 

SI .4.1. 
1 

The structure must provide a means of 
attachment for all components that does not 
rely solely on friction 

SI. 4.1 

Every component should be 
rigidly mounted to the structure 


CASTOR 

Design 

Document 

Design 

Requirement 

SI .4.1. 
2 

CASTOR components must comply with 
outgassing, corrosion resistance, and 
flammability resistance requirements 

SI. 4.1 

Materials must not have 
excessive outgassing, must not 
deteriorate, and must not be 
significantly flammable. 


CASTOR 

Design 

Document 

Master Materials 
List 

SI. 4.2 

The satellite structure must survive the launch 
environment and interface with the LV 

SI. 2 

The structure must be intact after 
separation 


CASTOR 

Design 

Document 

Vibration Test 

SI. 4.2. 
1 

The satellite shall have a natural frequency of 
at least 100 Hz in each direction 

SI. 4.2 

Designing to be above the 
natural frequency for all launch 
vehicles 


CASTOR 

Design 

Document 

Vibration Test 

SI. 4.2. 
2 

The satellite shall withstand a load of 20 g's 
in each direction 

SI. 4.2 

Designing to be above the 
acceleration loads for all launch 
vehicles 


CASTOR 

Design 

Document 

Vibration Test 

SI. 4.2. 
3 

The CG for the satellite shall be less than 0.5 
cm from the Lightband centerline, including 
manufacturing tolerances 

SI. 4.2 

The CG must be near the 
Lightband centerline to ensure 
the satellite behaves predictably 
during separation 


CASTOR 

Design 

Document 

Vibration Test 

SI. 4.2. 

4 

The CG must lie less than 40 cm above the 
SIP (+Z axis) 

SI. 4.2 

The CG must be near the LV to 
ensure the satellite behaves 
predictably during separation 


CASTOR 

Design 

Document 

Vibration Test 

SI. 4.2. 
5 

The satellite shall be mounted to the LV 
interface via a PSC Motorized Lightband 
system 

SI. 4.2 

The Lightband is the separation 
mechanism and LV interface 
identified for use for UNP-6 and 
CASTOR 


CASTOR 

Design 

Document 

Vibration Test 

SI. 4.3 

The structure shall support deployable solar 
panels 

S1.2, 

Sl.3.1. 

3 

Body-mounted solar panels do 
not provide the power required 
by EPS 


CASTOR 

Design 

Document 

FlatSat IV 

SI. 4.4 

The satellite structure at launch shall fit into a 
50 cm x 50 cm x 60 cm volume, not 
including Lightband interface 

MC.l 

UNP User's Guide requirement 


CASTOR 

Design 

Document 

Design 

Requirement 

SI. 4.5 

The mass of the satellite shall not exceed 50 
kg 

MC.l 

UNP User's Guide requirement 


CASTOR 
Mass Budget 

CASTOR Mass 
Budget 

SI. 4.6 

The factor of safety for analysis must be 
above 2 for yield and 2.6 for ultimate 

MC.l 

UNP User's Guide requirement 


CASTOR 

Design 

Document 

Vibration Test 
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CASTOR Thermal 






SI .5.1 

The satellite must have adequate thermal 
protection during all mission phases to keep 
all components within operational 
temperature ranges 

SI. 2 

Components must keep in 
certain temperature ranges so 
that their functionality or 
structural integrity is not 
compromised and they can carry 
our their intended task 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

1 

CASTOR thermal system will keep 
components within 2 °C of the upper and 
lower operating limits during operations, and 
within 5 °C of survivable limits at all times. 

Sl.5.1 

This gives some leeway 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

1.1 

NiCd Batteries shall operate between (0 to 
70) °C, and shall be kept within survival 
range of (-20 to 75) °C at all times 

Sl.5.1 

NiCd Spec Sheet 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

1.2 

MPPT shall operate between (-40 to 60) °C, 
and shall be kept within survival range of (- 
45 to 80) °C at all times 

Sl.5.1 

MPPT Spec Sheet 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

1.3 

PPU shall operate between (-45 to 85) °C, and 
shall be kept within survival range of (-45 to 
95) °C at all times 

Sl.5.1 

PPU Spec Sheet 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

1.4 

PDU shall operate between (-55 to 100) °C, 
and shall be kept within survival range of (- 
65 to 1 10) °C at all times 

Sl.5.1 

PDU Spec Sheet 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

1.5 

MEMS IMU shall operate between (-40 to 
85) °C, and shall be kept within survival 
range of (-55 to 85) °C at all times 

Sl.5.1 

MEMS IMU Spec Sheet 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

1.6 

Reaction Wheels shall operate between (-20 
to 60) °C, and shall be kept within survival 
range of (-35 to 70) °C at all times 

Sl.5.1 

Reaction Wheel Spec Sheet 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

1.7 

GPS unit shall operate between (-20 to 50) 
°C, and shall be kept within survival range of 
(-30 to 60) °C at all times 

Sl.5.1 

GPS Spec Sheet 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

1.8 

Camera shall operate between (-20 to 60) oC, 
and shall be kept within survival range of (- 
35 to 85) oC at all times 

Sl.5.1 

Camera Spec Sheet 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

1.9 

DCFT shall operate between (0 to 200) °C, 
and shall be kept within survival range of (- 
50 to 300) °C at all times 

Sl.5.1 

Testing see document 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

1.10 

Xenon gas shall remain above (23) °C during 
DCFT operations 

Sl.5.1 

Nasa requirement 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

2 

UNP compliant optical materials (surfaces 
finishes and insulations) shall be used where 
possible/necessary to passively control the 
tank, solar panels, and critical components 

Sl.5.1 



CASTOR 

Design 

Document 

Master Materials 
List 

Sl.5.1. 

3.1 

Thermal models of the satellite shall be 
supplied to AFRL and at a minimum shall 
consist of a simplified model that includes 
nodes for each of the temperature critical 
components 

MC.l 

UNP User's Guide 


CASTOR 

Design 

Document 

Thermal 

Model/T-Vac 

Sl.5.1. 

3.4 

A list of all payload external surface 
properties, including area (size), 
material/process, absorptivity, and emissivity, 
shall be provided 

MC.l 

UNP User's Guide 


CASTOR 

Design 

Document 

Master Materials 
List 

SI. 5.2 

The satellite’s components shall be monitored 
by thermal sensors, which shall interface with 
the avionics system and be compatible with 
the available power 

SI. 2 

To monitor component’s 
temperature in order to 
determine if reorientation is 
necessary to keep components 
within specified temperature 
ranges as well as monitor the 
status of the DCFT engine 


CASTOR 

Design 

Document 

FlatSat II 
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SI. 5.2. 
1 

The satellite shall have 20 number of thermal 
sensors consisting of 6 K-type thermocouples 
and 1 4 LM 1 9 analog sensors in order to 
accurately monitor the temperature of 
components. 

Sl-2 

See Design Doc. 


CASTOR 

Design 

Document 

Design 

Requirement 

SI. 5.2. 
1.3 

All Thermal Hardware on the satellite shall 
be calibrated for an accuracy to +/- 2 oC 
degrees. 

SI -2 



CASTOR 

Design 

Document 

FlatSat II 

SI .5.2. 
1.4 

All Thermal Hardware on the satellite shall 
take readings every 1 20 seconds. 

Sl-2 

This will ensure that the temps 
are in the specified ranges. This 
will be sent down to the ground 
station. 


CASTOR 

Design 

Document 

FlatSat II 

SI. 5 .2. 
2 

Thermal readings shall be provided to the 
ground station from the satellite every 90 
minutes. 

Sl-2 

needed for analysis purposes 


CASTOR 

Design 

Document 

FlatSat I 









CASTOR ADCS 






Sl.6.1 

ADCS shall provide pointing knowledge to 
distinguish DCFT efficiency changes from 
pointing errors, to allow for attitude control, 
and to enable effective communications with 
the ground station. Objective: 1 degree, 
Threshold: 5 degrees 

SI. 3, 
SI. 10.3 

The orientation of the engine 
firing angle with respect to the 
body and inertial space must be 
known to account for loss of 
delta-V efficiency; there is less 
than 0.4% error for 5 degree of 
knowledge. Additionally, 
sensing must be finer than 
control authority and 
communication system requires 
attitude knowledge 


CASTOR 

Design 

Document 

ADCS 

Simulation/Magn 
etometer Test/ 
Reaction Wheels 
Test/ FlatSat III/ 
GPS Test 

SI. 6.1. 
1 

ADCS sensors shall provide position data to 
processor. Objective: 1Hz, Threshold: 0.2Hz 

Sl.6.1 

Sensing in control loop must be 
fast enough in order to meet 
pointing requirements 


CASTOR 

Design 

Document 

FlatSat m 

SI. 6.2 

ADCS shall provide 3-axis attitude control 
authority to enable proper pointing of the 
body, solar arrays, and engine. Objective: 5 
degree. Threshold: 25 degrees 

S-2, S- 
3 

Control affects solar panel 
output and operational 
predictability and safety, 25 
degrees pointing represents less 
than a 1 0% loss in power 
generation or thrust direction 


CASTOR 

Design 

Document 

Torque Coils 
Test/ Reaction 
Wheels Test 

SI. 6.2. 
1 

ADCS shall be able to slew 1 8 deg/min 

SI. 6.2 

The DCFT will not be operating 
in eclipse and the worst case 
orientation is 1 80 degrees. To 
ensure the thrust is in the proper 
direction, the satellite must be 
able to be pointed in the correct 
orientation within 1 0 minutes 


CASTOR 

Design 

Document 

tested using 
reaction wheel 
models and air 
bearing 

SI. 6.2. 
2 

ADCS shall have sufficient components to 
store and manage angular momentum 

SI. 6.2 

In order to have proper control 
throughout the lifetime of 
CASTOR, angular momentum 
must be managed by the ACS 


CASTOR 

Design 

Document 

Torque Coils 
Test/ Reaction 
Wheels Test 

SI. 6.2. 
3 

The ADCS subsystem shall apply net forces 
to the spacecraft under 10' 3 N. 

SI. 6.2 

Minimize disturbance to GNC 
and engine system 


CASTOR 

Design 

Document 

ADCS 

Simulation/Magn 
etometer Test/ 
Reaction Wheels 
Test/ FlatSat III/ 
GPS Test 

SI. 6.2. 
4 

ADCS actuators shall follow a commanded 
torque from processor. Objective: 1Hz, 
Threshold: 0.2Hz 

SI. 6.2 

Actuator must be commanded 
fast enough in order to meet 
pointing requirements 


CASTOR 

Design 

Document 

FlatSat III 
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SI. 6.3 

ADCS components must comply with 
material and structural requirements 

SI. 4.1. 
2 

ADCS components will meet or 
exceed mass and power 
minimum requirements. Physical 
interfaces will be verified. 


CASTOR 

Design 

Document 

Vibration 
Test/Master 
Material List 

SI. 6.3. 
1 

ADCS components must comply with 
requirements for outgassing, corrosion 
resistance, and flammability resistance 

Sl.4.1. 

2 

Materials must not have 
excessive outgassing 


CASTOR 

Design 

Document 

Master Materials 
List 

SI. 6.3. 
2 

ADCS components must meet UNP vibration 
requirements 

Sl.4.1. 

2 

ADCS components must not 
cause or be damaged during 
launch 


CASTOR 

Design 

Document 

Vibration Test 

SI. 6.3. 
3 

ADCS components must minimize power 
usage 

SI. 6.2 

In order to meet mission 
requirements, ADCS power 
must be conserved and 
minimized 


CASTOR 

Design 

Document 

engineering 
model testing 









CASTOR GNC 






SI .7.1 

CASTOR shall have on-orbit GNC 
knowledge to manage DCFT operations and 
measure real-time position and velocity 

SI. 2 

GNC information is necessary 
for autonomous commanding of 
thrusting times and desired 
engine pointing vector, and 
gives data on the change in the 
orbit 


CASTOR 

Design 

Document 

FlatSat III/GPS 
Test/ IMU test 

SI. 7.1. 
1 

GNC system shall be able to have on-orbit 
positioning knowledge within 1km while 
operating DCFT 

SI .7.1 

Accurate positioning knowledge 


CASTOR 

Design 

Document 

GPS Test 

SI .7.1. 
2 

GNC system shall be able to have velocity 
knowledge within 10 m/s while operating 
DCFT 

SI. 3, 
SI. 7.1 

Accurate velocity knowledge 
and sensing orbital changes 


CASTOR 

Design 

Document 

IMU Test 

S.l.7.2 

GNC system shall provide orbital state data 
to the avionics system to manage 
communications and determine the sun angle 

SI. 2 

Satellite must know when it is 
over the ground station to 
initiate communications and the 
position of the sun is necessary 
for power generation 


CASTOR 

Design 

Document 

FlatSat III 









CASTOR Avionics 






SI .8.1 

Avionics system shall provide the necessary 
data interfaces to support all subsystems 

SI. 2 

Satellite requires operational 
controls 


CASTOR 

Design 

Document 

FlatSat X 

SI .8.1. 

1 

Avionics will continually monitor the 
propulsion system to ensure that the thruster 
does not spuriously activate 

SI .8.1 

Sensor data required for accurate 
determination of satellite state. 


CASTOR 

Design 

Document 

FlatSat II 

SI .8.1. 
2 

Avionics will run the propulsion system's 
engine firing logic twice per orbit. 

SI .8.1 

Engine firing control required to 
keep stable orbit. 


CASTOR 

Design 

Document 

FlatSat III 

SI .8.1. 
3 

Avionics will interface with the ADCS 
subsystem to execute a Kalman Filter using 
sensor data to accurately determine the 
satellite state and implement a PD control law 
for state corrections at a frequency of 1 Hz. 

SI .8.1 

Attitude control necessary for 
propulsion and imaging to 
operate as required. 


CASTOR 

Design 

Document 

FlatSat IV 

SI .8.1 . 

4 

Avionics will provide the computation 
necessary for navigation control through the 
use of GPS data collection and an SGP4 
Propagator at a frequency of 1 Hz. 

SI .8.1 

Interface crucial for accurate 
determination of satellite 
position. 


CASTOR 

Design 

Document 

FlatSat IV 

SI .8.1 . 
5 

The Avionics subsystem shall interface with 
the communications subsystem to send and 
receive data when communications 
capabilities are available. 

SI .8.1 

Data must be downlinked from 
the DCFT and it must be 
possible for commands to be 
uplinked to the satellite. 


CASTOR 

Design 

Document 

FlatSat I 

SI .8.1 . 
5.1 

In order for communications to occur the 
Avionics system will packetize, send, and 
verify that all data is sent and received. 

SI .8.1 . 
5 

It is critical to ensure that data is 
not lost in the communications 
channel 


CASTOR 

Design 

Document 

FlatSat I 
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Sl.8.1. 

6 

Avionics will provide the interface for power 
systems to monitor critical power levels and 
execute fail safes if necessary at a frequency 
of 4 Hz. 

Sl.8.1 

Avionics will provide the 
control logic to ensure that 
power is properly distributed 
around the satellite 


CASTOR 

Design 

Document 

FlatSat m 

Sl.8.1. 

7 

Avionics will interface with the imaging 
device to facilitate the capture and storage of 
images. 

Sl.8.1 

Images of the DCFT plume will 
be used to verify proper 
operation of the thruster, 
avionics will be in charge of 
ensuring that the imaging system 
accomplishes this 


CASTOR 

Design 

Document 

FlatSat II 

Sl.8.1. 

7.1 

Avionics will be capable of capturing and 
storing at least 1 image per orbit without 
overriding the data for 2 weeks. 

Sl.8.1 

The avionics must be robust 
enough to store the imaging data 
through an elongated period 
without communicating with the 
ground station 


CASTOR 

Design 

Document 

FlatSat II 

SI. 8.2 

Avionics system shall provide the computing 
power and data storage capacity to process 
and store all necessary state data. 

SI. 2, 
S1.3 

The computing power is 
necessary for ACS/GNC and 
general system tasks, and data 
storage is necessary for 
downlinking desired state data 


CASTOR 

Design 

Document 

FlatSat x 

SI .8.2. 
1 

The avionics system's processors must be 
able to handle all of the calculations required 
to run all subsystems in real time. 

SI. 8.2 

Three dsPIC’s are necessary for 
load balancing and redundancy. 


CASTOR 

Design 

Document 

FlatSat x 

SI. 8.2. 
2 

There will be enough flash memory available 
for storage of critical data and operational 
code. 

SI. 8.2 

1 GB of flash memory used for 
storage of large data sets and 
images. Onboard memory used 
for transient storage of data. 


CASTOR 

Design 

Document 

FlatSat x 

SI. 8.3 

Avionics system shall be fault tolerant and 
able to recover from SEU failure. 

S1.2 

Satellite will be flying in LEO 
and be subject to radiation 


CASTOR 

Design 

Document 

SEU test 

SI .8.3. 

1 

SEU failures shall be detected by checksums 
of the memory and storage to determine data 
integrity at a frequency of 0.01 Hz. 

SI. 8.3 

Checksums can detect 
discrepancies caused by SEU 
failures. 


CASTOR 

Design 

Document 

SEU test 

co 

00 

00 <N 

Through reprogramming or rebooting the 
avionics system shall be able to recover from 
an SEU fault in under 1 minute from the time 
of detection. 

SI .8.3 

It is critical that the avionics 
system be able to quickly 
recover after a SEU. 


CASTOR 

Design 

Document 

SEU test 

SI. 8.4 

Avionics system shall retain programming 
and state when unpowered 

SI. 2 

Satellite must be able to power 
on after being powered off for 
storage and launch 


UNP User’s 
Guide 

Datasheet 

SI .8.5 

Avionics system shall permit software 
updates for upgrading running software and 
recovering from SEU faults. 

SI. 2 

Software needs to be replaced or 
changed to allow for upgrades 


CASTOR 

Design 

Document 

avionics FlatSat 









CASTOR Software 






SI. 9.1 

Software shall be capable of performing a 
cold startup, self-test, and establish a comm 
link 

SI. 2 

Satellite hardware must be 
activated after separation from 
the launch vehicle 


CASTOR 

Design 

Document 

avionics FlatSat 

SI. 9.2 

Software shall support communications, 
operations, scheduling, and health monitoring 

SI. 2 

Software is necessary for 
managing all system tasks, to 
include engine operations, 
attitude, data storage, and 
communications 


CASTOR 

Design 

Document 

FlatSat x 

SI. 9.2. 
1 

Software will have access to enough memory 
to support all operations 

SI. 9.2 

Adequate memory (both RAM 
and Mass Storage) will be 
provided to the avionics 
software to support all 
operations. 


CASTOR 

Design 

Document 

FlatSat x 
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SI .9.2. 
2 

Software shall integrate ADCS/GNC data to 
perform estimation and control 

SI. 2. 
SI. 9.2 

The engine should be pointed 
before being fired and the 
satellite should know its location 
for operations scheduling 


CASTOR 

Design 

Document 

ACS FlatSat 

SI. 9.2. 
2.1 

Software will implement a Kalman filter to 
perform estimation necessary and implement 
a PD control law to establish control of the 
vehicle for ADCS. 

SI. 9.2. 
2 

Attitude control necessary for 
propulsion and imaging to 
operate as required. 


CASTOR 

Design 

Document 

ACS FlatSat 

SI. 9.2. 
2.2 

Software will process GPS data and 
implement an SPG4 propagator to provide 
GNC estimation. 

SI. 9.2. 
2 

Crucial for accurate 
determination of satellite 
position. 


CASTOR 

Design 

Document 

ACS FlatSat 

SI .9.2. 
3 

Software shall interface with the DCFT/PPU 

Sl.l, 
SI. 9.2 

The engine must be controlled in 
software since it requires 
complex timings and feedback 
for verification 


CASTOR 

Design 

Document 

FlatSat II 

SI .9.2. 
4 

Communications support will include storing 
data, packetizing data, and ensuring the 
integrity of the data received by the ground 
station. 

SI. 9.2 

Communications with the 
ground station is vital for 
mission success, so that image 
data can be downlinked and 
commands uplinked 


CASTOR 

Design 

Document 

FlatSat I 

S 1 .9.2. 
5 

Software shall execute the processes 
necessary to collect sensor data to ensure the 
necessary information is available for all 
subsystem operations. 

SI. 9.2 

Maintaining health data for all 
subsystems is critical to ensuring 
proper functionality of the 
satellite 


CASTOR 

Design 

Document 

FlatSat II 

SI. 9.2. 
6 

Software will use a RTOS to implement the 
scheduling of all processes required by 
satellite subsystems to ensure accurate timing 
constraints are met. 

SI. 9.2 

The strict scheduling 
requirements of the spacecraft 
require the use of a RTOS for 
timing purposes 


CASTOR 

Design 

Document 

software test 

SI. 9.2. 
7 

Software will implement continual 
checksums of available memory to monitor 
for SEU faults and other errors in operations. 

Sl.9.2 

To avoid errors due to SEUs, the 
Avionics software will 
continually be looking out for 
errors 


CASTOR 

Design 

Document 

SEU Test 

SI. 9.3 

Software should provide the ability to 
reprogram the flight computers 

SI .8.3 

Software needs to be replaced in 
the event of SEU or errors 


CASTOR 

Design 

Document 

software test 








S.1.10 

CASTOR Communications 






S.1.10. 

1 

The communications subsystem shall provide 
the ability to transmit commands from the 
ground station to the satellite. 

SI. 2 

Ground station must be able to 
command and control the 
satellite 


FlatSatl 

Result 

Document 

FlatSat 1/ Antenna 
Testing 

SI. 10.1 
.1 

The communications subsystem shall be 
equipped with a dish and a modem at the 
ground station. 

S1.10.I 

Minimum equipment necessary 
to perform the functionality 
required by 1 . 1 0. 1 


CASTOR 

Design 

Document 

Design 

Requirement 

SI. 10.1 
.2 

The communications subsystem shall provide 
the ability for the satellite to receive 
commands from the ground station. 

SI. 10.1 

Ground station must be able to 
command and control the 
satellite 


FlatSatl 

Result 

Document 

FlatSat V 
Antenna Testing 

SI. 10.1 
.2.1 

The communications subsystem shall be 
equipped with at least one antenna and one 
modem on the satellite. 

SI. 10.1 
.2 

Minimum equipment necessary 
to perform the functionality 
required by 1.10.1.2 


Castor Design 
Document 

Design 

Requirement 

SI. 10.2 

The communications system shall be able to 
establish a robust and periodic link 

S1.2 

Ground station contact with 
HETE only lasts for 8-12 
minutes per pass and 
communications interruptions 
must be handled gracefully 


CASTOR 

Design 

Document 

FlatSat I 
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SI. 10.2 
.1 

The communications subsystem shall 
recognize correct packets from incorrect 
packets and be able to request retransmission 
if the packet is faulty. 

SI. 10.2 

In order to request 
retransmission and to avoid the 
execution of wrong commands 


CASTOR 

Design 

Document 

FlatSat I 

SI. 10.2 
.1.1 

The link layer protocol, from the modem, 
shall be able to recognize correct packets 
from incorrect packets and be able to request 
retransmission if the packet is faulty. 

SI. 10.2 
.1 

Derived from 1.10.2.1 


CASTOR 

Design 

Document 

FlatSatl 

Result 

Document 

FlatSat I 

SI. 10.2 
.1.2 

The upper layer protocol, from the software 
on the satellite and ground station, shall be 
able to recognize correct packets from 
incorrect packets and be able to request 
retransmission if the packet is faulty. 

SI. 10.2 
.1 

Derived from 1.10.2.1 


CASTOR 

Design 

Document 

FlatSat I 

SI. 10.2 
.2 

The satellite shall be able to receive a set-up 
ACK from the ground station and start a 
communications link 

SI. 10.2 

The ground station will start the 
communication session, but the 
satellite has to be able to react 
and to start transmitting data 


CASTOR 
Design 
Document , 
FlatSat 1 
Result 
Document 

FlatSat I 

SI. 10.2 
.2.1 

The modem shall be able to wake up from 
sleeping mode when commanded to so as to 
start a communications link. 

SI. 10.2 

Modem will be in sleep 
modeffor power reasons) until 
the system is ready to 
communicate 


CASTOR 

Design 

Document 

FlatSat I 

SI. 10.2 
.3 

The communications subsystem shall be able 
to store packets to prevent overflow. 

SI. 10.2 

The communication sessions 
will be limited up to a maximum 
of 30 minutes per day, hence 
packets need to be stored before 
the transmission 


CASTOR 

Design 

Document 

FlatSat I 

SI. 10.2 
.3.1 

The communications protocol shall be able to 
set up packet queues on the satellite and the 
ground station. 

SI. 10.2 
.3 

Derived from 1.10.2.3 


CASTOR 

Design 

Document 

FlatSat I 

SI. 1 0.2 
.4 

The communications subsystem shall be able 
to identify missing packets and out of order 
packets. 

SI. 10.2 

Especially for telemetry and 
commands, both ground station 
and satellite need to recognize if 
some piece of the transmission 
have been lost, in order to ask 
for retransmission 


CASTOR 

Design 

Document 

FlatSat I 

SI. 10.2 
.4.1 

The communications protocol shall be able to 
identify missing packets and out of order 
packets. 

SI. 10.2 
.4 

Derived from 1.10.2.4 


CASTOR 

Design 

Document 

FlatSat I 

SI. 10.3 

The communications subsystem shall be able 
to support a bandwidth and data rate 
necessary to transmit all telemetry (67bps) 
and pictures (2 per orbit 640*480 pixels). 

S1.3 

Series of complete pictures 
necessary for measurement of 
engine degradation. Engine 
operation verification at the 
ground station requires sufficient 
system health data as well as 
detecting problems 


CASTOR 

Design 

Document 

Design 

Requirement 

SI. 10.4 

The communications subsystem shall be fully 
redundant 

S1.2 

To counteract loss of coverage 
or single element failure which 
can cause loss of mission 


CASTOR 

Design 

Document 

Design 

Requirement 

SI. 10.4 
.1 

The communications subsystem shall be 
equipped with 2 antennas 

SI. 10.4 

Derived from previous 
requirement 


CASTOR 

Design 

Document 

Design 

Requirement 

SI. 10.4 
.2 

The communications subsystem shall be 
equipped with 2 modems 

SI. 10.4 

Derived from previous 
requirement 


CASTOR 

Design 

Document 

Design 

Requirement 









CASTOR Ground 
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S2-1 

Ground must be able to control the satellite 

M.l, 

M.2 

Ground-based command 
necessary to schedule engine 
firing and problem recovery 


Con-Ops 
Document& 
Castor Design 
Document 

FlatS at x 

S2-2 

Ground must be able monitor satellite 
performance and efficiency 

M.2 

Comparing operational data to 
simulation permits verification 
of the validity of our models 


Con-Ops 

Document 

FlatSat I 









CASTOR Ground Communications and 
Operations 






S2.1.1 

Ground shall provide the capability to 
communicate with the satellite 

S2-1 

To control the satellite, ground 
station must establish 
communications with the 
satellite 


CASTOR 

Design 

Document 

FlatSat V 
Antenna Testing 

S2.1.2 

Ground should provide the functionality to 
upload new programs to the satellite 

S2-1 

Software upload capability 
requirement comes from the 
requirement of the avionics to be 
reprogrammable in-flight 


CASTOR 

Design 

Document 

FlatSat I 

S2.1.3 

Ground should implement closed loop ACK 
on commands 

S2-1 

Operational control requires full, 
lossless upload of command data 


CASTOR 

Design 

Document 

FlatSat I 

S2.1.4 

Ground shall have the ability to identify 
errors in pictures and request retransmit 

S2-1 

Images of engine firing must be 
usable for engine degradation 
analysis 


CASTOR 

Design 

Document 

FlatSat I 

S2.1.5 

Ground must be manned by qualified staff 
while in communications with CASTOR 

S2-2 

An operator must be on hand to 
interpret satellite data, issue 
commands, and debug problems 


CASTOR 

Design 

Document 

License 

S2.1.6 

Ground must be able to simulate the satellite 
and predict future state 

S2-2 

Simulation permits verification 
that DCFT performance meets 
expectations 


CASTOR 

Design 

Document 

FlatSat x 









CASTOR Mobile Ground Support 
Equipment 






S2.2.1 

CASTOR shall have a battery charging and 
monitoring devices 

MC.l 

UNP User's Guide 




S2.2.6 

Maintain class 100,000 clean conditions 

MC.l 

UNP User's Guide 




S2.2.7 

Provide electrostatic discharge (ESD) 
protection to the satellite 

MC.l 

UNP User's Guide 




S2.2.8 

Have a means for grounding the container 
from an external grounding point before 
opening container 

MC.l 

UNP User's Guide 




S2.2.9 

Enable Shipping both with and without the 
Planetary Systems Corporation (PSC) 
Lightband integrated to the nanosatellite. 

MC.l 

UNP User's Guide 




S2.2.10 

Measure the shock environment experienced 
by the satellite during shipping through the 
use of shock sensors in all 3 axes. 

MC.l 

UNP User's Guide 




S2.2.11 

Must function with inhibited satellite system 

MC.l 

UNP User's Guide 




S2.2.12 

Must provide power to the satellite while it is 
inhibited 

MC.l 

UNP User's Guide 




S2.2.13 

Must charge/discharge batteries while 
inhibited 

MC.l 

UNP User's Guide 




S2.2.14 

Must support subsystem functional testing 

MC.l 

UNP User's Guide 




S2.2.15 

Must have fully protected circuitry and 
communications 

MC.l 

UNP User’s Guide 




S2.2.2 

CASTOR shall have a transportation case 

MC.l 

UNP User's Guide 
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S2.2.2. 

1 

The transportation case must be portable 

MC.l 

UNP User's Guide 




S2.2.3 

CASTOR shall have a lifting harness 

MC.l 

UNP User's Guide 




S2.2.3. 

1 

Castor shall have a lifting harnesses designed 
to lift the nanosatellite from a single point 
above its center of gravity, in every 
orientation except upside down (+-X, +-Y, 
+Z) 

MC.l 

UNP User's Guide 




S2.2.3. 

2 

Castor shall have lifting equipment that is 
designed such that it will not contact the 
Lightband during integration and ground 
handling operations 

MC.l 

UNP User's Guide 




S2.2.3. 

3 

Lifting Harness shall be shipped in the 
shipping container 

MC.l 

UNP User's Guide 




S2.2.3. 

4 

Lifting Harness shall engage the 4 trusses of 
the satellite. 

MC.l 

UNP User's Guide 




S2.2.4 

Castor shall have Tabletop MGSE stands that 
are able to support the nanosatellite with, 
without, and with only half of the Lightband 

MC.l 

UNP User’s Guide 




S2.2.5 

CASTOR’S MGSE shall be designed using a 
factor of safety of 5.0 for ultimate failure, and 
be proof loaded to twice the design load 

MC.l 

UNP User's Guide 
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9.3 COST PROJECTION THROUGH SUMMER 2010 


Sub-team 

ITEM DESCRIPTION 

ESTIMATED 

COST 

ADCS 

Torque Coil 

$225.00 

ADCS 

Sun Sensor 

$90.00 

ADCS 

Microprocessor 

$105.00 

Avionics 

Camera x2 

$500.00 

Avionics 

DSC Board 

$150.00 

Comm 

Antennas 

$200.00 

Power 

Lambdas Converters 

$400.00 

Power 

PCB for new PXU 

$132.00 

Power 

Other Inverter expenses 

$150.00 

Power 

Solar Cell Test Boards 

$660.00 

Power 

Solar Panel Electrical Construction Items 

$100.00 

Power 

NiCd Battery Charging Chips and Test Boards 

$170.00 

Power 

MPPT components/new one 

$450.00 

Power 

Test Batteries (possibly different types) 

$500.00 

Power 

Miscilaneous Parts and Components 

$450.00 

Propulsion 

Flow Controllers (X2) 

$1,400.00 

Software 

GPS Simulator (Terrestrial) 

$100.00 

Software 

Miscellaneous Electronics for Ground Station (heavy margin) 

$500.00 

Structures 

SEM Aluminum 

$850.00 

Structures 

SEM Fasteners 

$400.00 

Structures 

Machining- Tank Clamps (Material, 

$750.00 

Thermal 

Thermal Sensors 

$100.00 

Thermal 

Thermocouples 

$300.00 

Thermal 

Thermalcouple control board 

$100.00 

Thermal 

Test Materials 

$200.00 

Thermal 

Surface Finishes 

$200.00 

Thermal 

Software 

$300.00 

Integrated 

Systems 

Lincoln Laboratory Test Campaign 

$4,500.00 





TOTAL: 

$13,982.00 





Additional: Clean Room and Electronics Room Tools 

$2,500.00 
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9.4 RISK ASSESSMENT MATRIX 
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Apnl 23, 2010 


ADCS 

Category 

Component 

Failure Mode 

Description 

Dependencies 

2-01 

Hardware 

GPS 

GPS Failure 

GPS provides incorrect position 
data or no position data 

Power (or converter) Failure 

2-02 

Hardware 

Sun Sensor 

Sun Sensor Single 
Failure 

One Sun Sensor provides 
incorrect sun position or no sun 
position 

Power (or converter) Failure 

2-05 

Hardware 

IMU 

IMU Rate Sensor 

Rate Sensor provides incorrect 
rate data or no rate data 

Power (or converter) Failure 

2-06 

Hardware 

Magnetometer 

Magnetometer 

Magnetometer provides incorrect 
magnetic field information or no 
magnetic field information 

Power (or converter) Failure 

2-07 

Operational 

Reaction Wheel 

Reaction Wheel Single 
Failure 

One Reaction Wheel fails to 
operate properly 

Power (or converter) Failure 

2-10 

Hardware 

Torque Coil 

Torque Coil Single 
Failure 

One Torque Coil does not 
provide expected magnetic 
dipole, or provides no magnetic 
dipole 

Power (or converter) Failure 

2-13 

Hardware 

Wiring Harness 

ADCS Wiring Harness 

Incorrect wiring that leads to any 
of the issues mentioned above 

avionics malfunction 


2-14 Hardware Sun Sensor Sun sensor output Outputs only one or two angle interface malfunction 

failure instead of three 











































2-15 


Software 


Magnetometer 


Magnetometer 

Miscalibration 






2-16 

Software 

Torque Coil 

Torque Coil Polarity 
Inversion 

2-17 

Software 

Software 

General Software Errors 


Magnetometer readings do not 
match expected values from 
IGRF Model 


control law avionics 


Torque coils provide opposite 
torque than expected 

control law, avionics 

Software errors that lead to any 
of the issues mentioned above 

control law, avionics 













Continuation of ADCS Risks 


ADCS 

Mitigation 

Diagnostic 

Repair 

Backup 

TRL 

Severity 

Likelihood 

Risk 

Level 

Date 

2-01 

Satellite orbital 
position can be 
found by 
propagating 
TLEs 

thorough 

testing 

None 

TLR 


2 

2 

low 

4/9/2010 

2-02 

Thorough 
testing and 
evaluation of 
sun sensor 
functionality and 
interface design 

thorough 

testing 

none 

other sun 
sensors 

8 

2 

2 

low 

4/9/2010 

2-05 

Functionality 
testing and 
interface testing 
IMU is not 
necessary for 
measuring 
attitude but it 
provides more 
assurance This 
is a redundant 
system 

no readings 

none 

GPS, sun 
sensors 


2 

2 

low 

4/9/2010 

2-06 

Functionality 
testing interface 
testing and 
calibration 
against a known 
magnetic field 

no readings 

none 

sun 

sensors 
IMU GPS 


4 

2 

MED 

4/9/2010 


Updated 

By 


Danielle 

DeLatte 


Danielle 

DeLatte 


Danielle 

DeLatte 


Danielle 

DeLatte 































2-07 Functionality no readings none 
testing and 
interface testing 
If a single wheel 
fails, required 
slew maneuvers 
can be 

completed over 
longer period of 
time using the 

torque coils 

2-10 Thorough no readings none 

testing and 
evaluation of 
torque coil 
functionality and 
interface design 
If one torque 
coil fails the 
other two coils 
will be able to 
provide enough 
torque to 
desaturate the 
reaction wheels 
in an extended 
period of time 



Individual and thorough none 

integrated testing 

wiring tests to 

ensure expected 

functionality 

Avionics in 

charge of this 


torque coils 
can control 
attitude but 
it's very 
slow 


rely on 
other two 


avionics 


2 


MED 


4/9/2010 Danielle 
DeLatte 






3 

MED 

4/9/2010 

Danielle 

DeLatte 

2 

MED 

4/9/2010 

Danielle 

DeLatte 













2-14 140° field of 

view having 
more helps but 
is not necessary 


2-15 

Careful 
calibration of 
magnetometer 
If calibration is 
off can be 
recalibrated on 
orbit 

2-16 

Dipole testing 
before and after 
integration If 
polarity is 
reversed can be 
corrected on 
orbit 

2-17 

Thorough 
software testing 
before and after 
integration If 
problems arise 
in software, new 
versions can be 
uploaded on 
orbit 


error recalibrated 

exception in orbit 


error software 

exception patch 


software 

patch 


error 

exception 


available 

angles 

sufficient 


software 

patch 

recalibrated 
in orbit 


software 

patch 


software 

patch 


2 

low 

4/9/2010 

Danielle 

DeLatte 

2 

low 

4/9/2010 

Danielle 

DeLatte 

2 

low 

4/9/2010 

Danielle 

DeLatte 


3 


MED 


4/9/2010 Danielle 
DeLatte 






















Avionics 

Category 

Component 

3-01 

Operational/Design 

PIC 

3-02 

Operational 

PIC SEU 

3-03 

Design 

PIC 

Communications 


Design 

PIC Deadlock 

3-05 

Operational 

Wires 


Operational 

Memory 


Design 

Memory 


Operational 

PIC 

3-09 

Operational 

Avionics Board 


Failure Mode 

PIC Failure 

PIC SEU 

Inter PIC 
Communications 

RTOS Software 
Deadlock 

Wire separation 
Memory corruption 
Memory overflow 

Invalid command 
Environmental Damage 


Description 

PIC hardware failure 


Dependencies 


Ions/Radiation causes a transistor 
to flip 

PIC communications failure 

Multiple threads lock waiting for 
eachother s signals 

Wire connections fail during 
operation 

Data in memory becomes 
corrupted 

Data buildup over time without 
deletion 

Incorrect/unusable commands are 
sent to avionics hardware 

Thermal/Vibrational/etc damage 
to avionics equipment 



Software/Hardware 
implementation error 
ThreadX software 
implementation error 
Wiring harnesses breaks 
Solder connections fail 
Data stored in memory 
becomes unreliable 
Data not correctly 
offloaded when 

appropriate 

Incorrect software 
implementation 
Heat/V ibration reach 
beyond controllable levels 






























Avionics 

Mitigation 

Diagnostic 

Repair 

Backup 

3-01 


PIC fails to 
respond 

hardware 

reset 

Redundant 

PICs 

3-02 

Radiation hard 

components 

chosen 

Software 

checksums 

Software 

reset 


3-03 

Robust inter 
communication 
interface 
redundant data 
channels 

Impossible 

messages 

received 


backup 
simple 
data bus 

3-04 

Software 
implementation 
designed to 
avoid 
deadlocks 

Software 

recognize 

Software 

recovery 

Software 

reset 

3-05 

Care in 
construction 
and design of 
wire 

connections 




3-06 


Data 

checksums 

Deletion of 

unreliable 

data 


3-07 

Ensure data is 
off loaded 
correctly in 
testing 

Memory 

Full 

Deletion of 

unnecessary 

data 


3-08 

Enforce strict 
and clear API 
for 

commanding 

avionics 

Hardware 

Interrupts 


disregard 

further 

commands 

from 

offending 


avionics 


Severity 


4 


2 


3 


3 




2 




Date 

Updated 

By 

1 


3/15/2010 

Steven 

Gomez 

3 

MED 

3/15/2010 

Steven 

Gomez 

1 

low 

3/15/2010 

Steven 

Gomez 

1 

low 

3/15/2010 

Steven 

Gomez 

1 

MED 

3/15/2010 

Steven 

Gomez 

3 

low 

3/15/2010 

Steven 

Gomez 

2 

low 

3/15/2010 

Steven 

Gomez 

2 

low 

3/15/2010 

Steven 

Gomez 






















































Comm 

Category 

Component 

Failure Mode 

Description 

Dependencies 

4-01 

Design 

Antenna 

Single patch antenna on 
outside before deployment 

If the new patch antenna configuration 
is used before deployment there will 
only be one operational antenna on the 
outside hence there will be no 
redundancy Still can communicate 
but less opportunity to communicate 

failure to deploy solar panels 

4-02 

Hardware 

Antenna 

Antenna switching 
fails(look at previous risk) 

System is set up to switch between 
antennas depending on which one 
provides a better communications link 


4-03 

Hardware 

Interfacing 

Interference between 
components 

There could be interference on the 
communications subsystem due to 
other components of the satellite 


4-04 

Hardware 

1 1 dBi Antenna 

Plastic antenna cover 
damaged 

Plastic cover of antenna might be 
damaged in space which could make 
the antenna inside perform sub 
optimally 

Debris from another satellite 
component or space dust harsh 
launch environment 

4-05 

Hardware 

8 dBi Antenna 

Plastic antenna cover 
damaged 

Plastic cover of antenna might be 
damaged in space which could make 
the antenna inside perforin sub 
optimally 

Debris from another satellite 
component or space dust harsh 
launch environment 


4-06 

Hardware 

Wires 

Connections failure 

A connection between antenna 
modem or a PIC could fail 

bad manufacturing 

4-07 

Hardware 

Modems 

Modem damaged 

Modem could be short circuited 

bad manufacturing, improper 
hardware integration 




















4-08 Hardware 


Modems 


2 Modems damaged/fail 


Both Modems could be short 
circuited 


two modem failures or 
combination of modem and 
wire failures, 


Communications continued 


Comm 

Mitigation 

Diagnostic 

Repair 

Backup 

TRL 

Severity 

Likelihood 

Risk Level 

Date 

Updated 

By 

4-01 

A possible solution is to put a 
6dBi antenna on the outside 
however this would require a 
switch between the 2 antennas 
A 3dB loss would be incurred 
but the link budget would 
remain fine 




3 

3 

3 

MED 

3/15/2010 

Michael 

Munoz 

4-02 

There is no way to overcome 
the failure of the switching 
mechanism however it is safer 
than having no switch and no 
second antenna to solve the 
previous risk 

more corrupt 

packets, 

higher 

occurrence of 
signal loss 

reset from 
ground 


3 

3 

3 

MED 

3/30/2010 

Michael 

Munoz 

4-03 

An EMI test will be performed 
to model and characterize the 
interference due to other 
components 




2 

unknown 

1 

# VALUE' 

3/30/2010 

Michael 

Munoz 

4-04 

Testing will be done at MIT 
Lincoln Lab on the antennas 
without their plastic covers to 
analyze their performance 




5 

1 

1 

low 

3/30/2010 

Michael 

Munoz 

















4-05 

Testing will be done at MIT 
Lincoln Lab on the antennas 
without their plastic covers to 
analyze their performance 



4-06 

Need to verify that the different 
connections between antennas 
modems and PICs are all 
strong and in a position where 
the connection cannot be lost 

send 

commands 

none 

4-07 

Need to ensure that the board 
where the modem will be 
placed on is properly designed 
to avoid such possibilities 

send 

commands 

none 


4-08 careful manufacturing & testing 


1 

low 

3/30/2010 

Michael 

Munoz 

1 

low 

3/30/2010 

Michael 

Munoz 


2 

MED 

3/30/2010 

Michael 

Munoz 

2 

MED 

3/30/2010 

Michael 

Munoz 






















Propulsion 

Category 

Component 

5-01 

Hardware 

NASA PCS 

5-02 

Hardware 

NASA PCS 

5-03 

Hardware 

Cathode 

5-04 

Hardware 

Cathode 

5-05 

Hardware 

Anode 

5-06 

Hardware 

Anode 

5-07 

Hardware 

Plumbing System 


Failure Mode 

feed system failure 

feed adjustment failure 
cathode poisoned 

keeper/heater failure 


anode material 
degradation 

no power to anode 
electrical inhibit failure 


Description 

Dependencies 

xenon is not fed at the rate 
expected 

none 

cannot adjust the mass flow of 
xenon to the thruster 

none 

if not conditioned properly 
cathode material may be 
irreparably damaged 

conditioning procedure not 
followed 

if the keeper or heater does not 
maintain the cathode at the 
appropriate temperature the 
conditioning procedure must be 
repeated or the thruster cannot 
be fired without risking damage 
to the cathode 

none if failure is in 
subcomponent power 
system failure could fail to 
deliver requisite power to 
heater/keeper 

after long periods of operation 
anode material will slowly 
degrade will eventually cease to 
operate 

none 

with no power to anode no 
potential across thruster and 
thus thruster will not operate 

power system failure 


one or more electrical inhibits 
fails to open 


power system failure or 
failure in the components 
themselves 



































5-08 Hardware 


Plumbing System 


tank adapter failure 


faulty tank adapter could allow 
xenon to leak 


none 


Propulsion continued 


Propulsion 

Mitigation 

Severity 

Likelihood 

Risk Level 

Date 

Updated By 

5-01 

during XFS integration testing will test to 
ensure feed system works as expected If 
system fails on orbit thruster will still 
operate as long as some minimum amount of 
Xenon is delivered to the thruster 

3 

2 

MED 

3/26/2020 

Keith Loebner 

5-02 

same as above 

3 

2 

MED 

3/26/2010 

Keith Loebner 

5-03 

Conditioning procedure has been tested 
repeatedly and is effective If cathode is 
poisoned it is unlikely that it will be able to 
operate at all leading to mission failure 

5 

1 

MED 

3/26/2010 

Keith Loebner 

5-04 

will test heater/keeper functionality during 
thruster testing, and try to mitigate possible 
power failures during integration testing with 
PPU 

4 

2 

MED 

3/26/2010 

Keith Loebner 

5-05 

normal part of DCFT operation, will not 
affect mission during expected lifetime 

1 

1 

low 

3/26/2010 

Keith Loebner 




































5-06 with no power, thruster cannot operate, but 
can operate on reduced power by firing for 
less time 

5-07 will test inhibits during integration testing 
but on orbit failure would end mission if 
xenon flow to thruster cannot be initiated 

5-08 will test component to try to guarantee space- 
worthiness if it does leak it will shorten 
mission lifetime but a small leak should still 
allow DCFT testing on orbit 



2 MED 3/26/2010 Keith Loebner 


MED 3/26/20 1 0 Keith Loebner 


1 low 3/26/20 1 0 Keith Loebner 














Power 

Category 

Component 

Failure Mode 

6-01 

Operational 

Anode 

High voltage from anode couples into 
system 

6-02 

Operational 

Batteries 

Batteries get memory 

6-03 

Operational 

PPU 200 Voltage 
Converter 

Voltage converter fails 

6-04 

Operational 

PPU 15 Voltage 
Converter 

Voltage converter fails 

6-05 

Operational 

PDU 3 3 Voltage 
Converter 

Voltage converter fails 


6-06 

Operational 

PDU 5 Voltage 
Converter 

Voltage converter fails 



Wires 

Wire becomes disconnected 

6-08 

Operational 

Solar Panels 

Solar panels do not point at the sun 


Description 


Dependencies 


Memory degrades in time, 
Less power storage 
capability as time goes on 


All components that get 
power from converter can't 
get power, Anode failure 

short circuited 

heater for propulsive heater 
fails 

short circuited 

All components that get 
power from converter can't 
get power, avionic board, 
thermal sensors & thermal 
sensors 

short circuited 

ADCS except torque coils 
(don't need converter, comm 
modem, linear actuator for 
deployment 

short circuited 

that component will fail 


reduced power input 

ADCS failure or 
deployment 
























failure 


6-09 

Operational 

MPPT 

MPPT fails 

Tracks max power in solar 
panels, distributes to 
components while charging 
batteries 


6-10 

Operational 

Battery Charging 
Circuit 

Charger fails to turn off 

batteries overcharge and stop 
working 


6-11 

Operational 

Solar Panels 

Solar cell breaks, strand of cells becomes 
inoperational 




Power continued 


Power 

Mitigation 

6-01 

isolated 

6-02 

testing, planned 
cycle change for 
improve 
performance, 
chosen battery for 
high performance 
during first year 

6-03 

testing careful 
manufacturing 

6-04 

testing careful 
manufacturing 


Diagnostic 


component 
failed/ no 
power 

component 
failed/ no 
power 



Likelihood 

Risk 

Level 

Date 

Updated 

1 

MED 

4/9/2010 

Manal 

Habib 

3 

low 

4/9/2010 

Manal 

Habib 

2 

MED 

4/9/2010 

Manal 

Habib 

2 

MED 

4/9/2010 

Manal 

Habib 































6-05 

testing careful 
manufacturing 

component 
failed/ no 
power 


testing careful 
manufacturing 

component 
failed/ no 
power 




6-08] 



6-09 

testing add 
charging circuit to 
improve 
performance 

no power to 
all 

components 

6-10 


no power to 
batteries 

6-11 




2 


MED 


4/9/2010 Manal 
Habib 


2 

MED 

2 

MED 

2 

MED 

2 

MED 

2 

MED 

2 

MED 


4/9/2010 

Manal 

Habib 

4/9/2010 

Manal 

Habib 

4/9/2010 

Manal 

Habib 

4/9/2010 

Manal 

Habib 

4/9/2010 

Manal 

Habib 

4/9/2010 

Manal 

Habib 



































Thermal 

Category 

Component 

Failure Mode 

7-01 

Operational 

Thermal Sensor 

Sensor Failure 

7-02 

Operational 

Thermal Sensor 

Erroneous Sensor Data 

7-03 

Operational 

Component 

Component Outside Temperature 
Range 


Therma 

1 

Mitigation 

Diagnostic 

Repair 

Backup 

7-01 

careful 

transport 

no 

temperature 

data 

Replace/Re 
pair Sensor 

spares on 
hold other 
sensors on 
satellite 

7-02 

careful 

transport 

erroneous 

temperature 

data 

Replace/Re 
pair Sensor 

spares on 
hold other 
sensors on 

7-03 

turn off/on 
high-power 
consumption 
units 

temp sensor 

None 

none 


L y 


9 


Description 

Dependencies 

no data 

connection breaks 

data from one sensor is 
noticibly different from 
another 

one of sensor failure, 
software failure, power 
failure calibration 
error 

Componenet exceeds 
operational temp range 

none 


Likelihoo 

d 

Risk 

Level 

Date 

Updated 

2 

low 

3/14/2010 

George 

Sondecker 

2 

MED 

3/14/2010 

George 

Sondecker 

2 

MED 

3/14/2010 

George 

Sondecker 

















































Structures 

Category 

Component 

Failure Mode 

Description 

Dependencies 

8-01 Transport 

Solar Panels 

Cracking 

Cover glass cracks during 
transport/launch 

None 

8-02 Operational 

Solar Panels 

Deployment Failure 

Linear actuator fail to operate or 
the panels become impinged on 
deployment mechanism 

Manufacturing failure linear 
actuator failure, or power to 
release mechanism failure 

8-03 Manufacturing 

Solar Panels 

Buckling 

Panel crushes near bolts 

None 

8-04 Operational 

Fastener 

Fastener breaks 

Bolt nut, insert failure during 
launch could significantly 
damage the launch vehicle and 
payloads 

Structural failure 

8-05 Operational 

Member 

member failure 

Excessive yielding or fracture 
during launch could significantly 
damage the launch vehicle and 
payloads 

Structural failure 

8-06 Operational 

Pressure Vessel 

vessel ruptures 

Rupture or rapid depressurization 
of the Xenon tank 

Burst disk fails to operate 


Structures continued 





























8-02|Build & Test Prototype 


release mechanisms, 
outward-facing panels 
modify duty cycle is occurs 
to mitigate adverse effects 

8-03 

Use inserts in panels 

8-04 Installing certified, NAS 


rated fasteners torqued to 
NASA specified values on 
Flight Model 

8-05 Conducted hand 


calculations, finite element 
modeling and vibrational 
tests to ensure structure 
meets g loading and vibe 
requirements Certified 
aluminum stock will be 
used on the flight model 


8-06 Tank will be loaded below 


its max rated pressure 
Burst disks on tank prevent 
catastrophic failure 



visible test replace 
panel 


vibe test 



replace remake 
structure part 




Sci/Pay Category 
9-01 Operational 


Component Failure Mode 

C328 Camera Lens Lens Degradation 



51 


3 


3 MED 


3/ 14/20 10 George Sondecker 








6 

3 

1 

low 

3/14/2010 

George Sondecker 

9 

4 

2 

MED 

3/14/2010 

George Sondecker 

9 

4 

2 

MED 

3/14/2010 

George Sondecker 

9 

3 

2 

MED 

3/14/2010 

George Sondecker 
































c 


9-02 

Operational 

C328 Module 

Overheat 

Module overheats due to solar 
radiation 


9-03 

Operational 

Shutter 

Shutter Failure 

Shutter either stays closed or 
stays open 


9-04 

Transport 

C328 Camera 

Misalignment 

Camera misaligns with shutter 
opening 



Science & Payload continued 


Sci/Pay 

Mitigation 

Diagnostic 

Repair 

Backup 

TRL 

Severity 

Likelihood 

Risk 

Level 

Date 

Updated 

9-01 

Protection via 
aluminum shield 
box shutter 

Blurry image 




4 

3 

MED 

3/15/2010 

Adnel 

Fidone 

9-02 

Heat is dispersed 
through truss 

Improper 

Functionality 




3 

2 

MED 

3/15/2010 

Adnel 

Fidone 

9-03 

Extensive shutter 
testing careful 
handling 

No visible 
image or 
Blurry image 




3 

2 

MED 

3/15/2010 

Adnel 

Fidone 

9-04 

Careful 
transportation, 
securely fastened 

Images of 
shield box 



■ 

3 

2 

MED 

3/15/2010 

Adnel 

Fidone 
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9.5 SCHEDULE 




